smartmatch/given: kill it with fire, fix it or bless it

[tonycoz]

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.

[tonycoz]

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.

[leonerd]

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?

[Leont]

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.

[tonycoz]

The same is true of shipping a significantly different version, which leaves us with the blessed wart.

[leonerd]

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.

[Leont]

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).