Open tonycoz opened 4 years ago
It might be tempting to just do new given/smartmatch behaviour in class/module/use v7, but that gives us two implementations of smartmatch to maintain, document and teach.
A really easy initial step might be just to not bundle it into use feature :VERSION
. Right now:
The following feature bundles are available:
bundle features included
--------- -----------------
:default array_base
:5.10 say state switch array_base
:5.12 say state switch unicode_strings array_base
...
:5.28 say state switch unicode_strings
unicode_eval evalbytes current_sub fc
postderef_qq bitwise
Maybe the next numbered feature bundle we release just gets rid of it again? Have we ever firmly committed to the fact that every numbered bundle is a superset of every previous one?
remove it from the language
I don't think that is an option, for all the reasons mentioned in #9. given
/when
has escaped into production a decade ago. Killing it at this stage is user-hostile, no matter how much we hate it.
The same is true of shipping a significantly different version, which leaves us with the blessed wart.
I've been having some vague thoughts about a new much-less-weird way of writing a few of the common cases - think basically Switch::Plain
but in-core (though I'm not yet ready to present it as a fully fleshed out idea). It might one day serve as a replacement for the 80-90% of common cases that people would currently use given
/when
for now.
I think the existing smartmatch and given
/when
are a dead duck at this point. We should remove them from the versioned feature bundles and document that we're definitely going to remove it from the default bundle at some future point.
But as @Leont points out, there's too much code in the wild for us to be able to remove it from the language itself at this stage. Maybe one day a time will come when smartmatch is the same as how we consider $package'name
now - a very old legacy feature we can probably get rid of if we try because really almost-nobody is actually using it. Removing it from the feature bundles will be another step in the direction of stopping people using it. People who actually want it can just ask for it, but they can do so knowing its days may be numbered.
The same is true of shipping a significantly different version, which leaves us with the blessed wart.
Yes and no. I'm pretty sure we can actually break HASH ~~ REGEX
without significant fallout, let alone REGEX ~~ HASH
. That table has 23 entries, but I've seen about 5 of them being used in production (outside of smartmatch modules on CPAN).
Related to #2 smartmatch/given/when have been in core, and then marked experimental for many versions without any change.
The times (time?) I recall attempting to fix it resulted in significant negative feedback.
I think we need to finally deciede the feature's fate.
The three possible fates:
remove it from the language, it's been marked experimental for a long time, so we could be considered justified in calling it a failed experiment and removing it
bless it - remove the experimental label
fix it - decide on new semantics, document them
Removing it: a) will break any code currently using the feature (-ve) b) such breakage will be loud, the user will have obvious fixes to make (+ve)
Blessing it: c) gives us a switch statement of sorts that can be used in stable code (+ve) d) gives us another language wart (-ve)
Fixing it: e) may silently change the behaviour of existing code (---ve) f) unwarts it (+ve)
We can partly avoid f) by requiring
use experimental "switch2"/"smartmatch2"
to use given/smartmatch with newer perls, but test suites and authors aren't perfect, so it might result in some unexpected breakage.