smartmatch/switch deprecation for 5.28

From: Zefram

Date: December 29, 2017 19:36

Subject: smartmatch/switch deprecation for 5.28

Message ID: 20171229193627.GB19698@fysh.org

December 29, 2017 19:36smartmatch/switch deprecation for 5.28

With smartmatch changes now reverted for 5.28, we need to decide pretty soon whether, and in which parts, smartmatch and switch should be deprecated in 5.28. We're going to need some kind of deprecation process to move forward with developing smartmatch, and there's obvious benefit in starting that process as early as possible. Of course, there's also danger in being hasty about the decision of what to deprecate. Opening position: I reckon that in the changes recently reverted we've got a pretty solid idea of what changes to smartmatch we actually want, and so we're in a position to deprecate immediately with that end in mind. We should not deprecate the entirety of smartmatch, but should deprecate all aspects of smartmatch and switch that are inconsistent with the prospective new behaviour. Handily, the choice of whereis/whereso keywords doesn't affect what needs to be deprecated, so we don't need to wait for us to find the right keywords. First cut of a list of things that would be deprecated: * smartmatch operation without a smartmatch-overloading object ref on the rhs * implicit enreferencement of argument expressions for ~~ and "given" * any use of "when", "default", or "break" * "next" et al skipping over a "given" block Some of the deprecation warnings would have to be generated at runtime, but should probably be limited to one warning actually emitted per op per program run. I imagine taking a slight liberty with thread-shared data structures, by setting an op_private bit to flag that the warning has been emitted. -zefram



