I don't know all the details

In a few words,

1. given, lexical $_ and smartmatching were added to Perl without enough vetting in 5.10.

2. In fact, smartmatching was so bad that it was tweaked in 5.10.1.

3. People starting noticing the problems with them, which resulted into a new policy: New features to be added to Perl would first be included as experimental features. By default, these warn when used.

4. given, lexical $_ and smartmatching were retroactively converted into experimental features in 5.18, effectively deprecating existing uses of them.

5. Lexical $_ was rolled back in 5.24.

6. given and smartmatching are being revamped for 5.28. It will still be an experimental feature, but it now has a chance of being released as normal part of Perl.

Thank you, ikegami. In fact, I knew about the history of smartmatch and given (as well as lexical $_). I was only saying that I don't know the details on the most recent developments as described by Leon and brian (i.e. your point 6) and the discussions around these. But it's probably good to retell the story for the benefits of those monks who would not know or not remember.

Two main threads:
http://markmail.org/message/u22titrq5ljclz4b
http://markmail.org/message/spv6sbj5lp2i4kht

I also have not ever used "smartmatch" and friends. I have never encountered it in code I've worked on at various employers, and that's neither because they were so clever, nor because they were all using old perls. It's because of the incredible confusion and instability around the "features," and also because no good use case for using them has been presented. What exactly is the problem that it's supposed to solve, that cannot be elegantly (enough) solved with normal loop and conditional constructs?

I will not shed a tear if smartmatch/given/etc. are reimplemented so code that uses them breaks (I expect that CPAN modules that break will be fixed), or if it completely goes away for now (which I think is the most sensible suggestion in the p5p thread that encapsulates the current debate).

However, I am alarmed at the process with which the changes have been already merged into bleadperl, as highlighted by LeonT and brian d foy. If that is the way things are going to get done, I fear that Perl will come to be viewed -- correctly -- as an unstable mess where there are no adults in charge.

In my opinion, that of a journeyman, workday Perl programmer, at the root of all this was the fiction that "Perl6" was a real thing in 2007, and the precipitous rush to implement many of its "features" in Perl v.5.10. Damian Conway and people who, like him, are outlandishly clever but also suffer from an excess of hubris, should be kept far away from the core of Perl!

I also have not ever used "smartmatch" and friends. I have never encountered it in code I've worked on at various employers,

I think you're trying to prove they're not a desired features, but it's far more likely that you've worked a companies that sensibly avoid using experimental (unstable) features in production code.

It's because of the incredible confusion and instability around the "features,"

There's no confusion; smartmatching is an experimental feature, not a stable feature. This will still be the case in 5.28. Continue not using it unless you want to be a beta tester.

I am alarmed at the process with which the changes have been already merged into bleadperl

Aye, there were problems, which were resolved by the creation of the policy and ability to make new features experimental.

Hi Ikegami, thanks for your reply. I was expressing alarm not at the introduction of smartmatch back in the day, but at the way in which it has been reimplemented in 5.27, i.e., apparently *not* following the policy its original introduction gave rise to. This is according to the articles mentioned above and my reading of the p5p thread, specifically that new keywords that have since almost universally met with scorn, were merged into blead with little or no discussion on the list, let alone off it.

I know that you are a p5p regular, perhaps you know different. Your perspective would be welcomed.

You can say that any sensible production code has always avoided smartmatch and given/when, but in fact it has been used in several CPAN modules that are themselves widely used in production, e.g. Type::Tiny and Try::Tiny, so isn't even a developer who has him/herself studiously avoided it because it's experimental, at risk of their code breaking through such changes?



The way forward always starts with a minimal test.

On rare occasions I've found it very convenient for debugging purposes, such as when I want to quickly compare two arrays.

If I recall correctly, last time I used it I was "cleaning up" some old code and I wanted a quick way to double check that the output array from the old code and the output array from the new code were exactly the same.

Just another Perl hooker - My clients appreciate that I keep my code clean but my comments dirty.

But why live with the warnings and the uncertainty about the function's future?

perl -wE '
my @foo = (1, 2, 3);
my @bar = (1, 2, 3);
my @baz = (1, 2, 4);
say "@foo" eq "@bar";
say "@foo" eq "@baz";
'
1
[download]

Or:

perl -MTest::Deep::NoTest=eq_deeply -wE '
my @foo = (1, 2, 3);
my @bar = (1, 2, 3);
my @baz = (1, 2, 4);
say eq_deeply \@foo, \@bar;
say eq_deeply \@foo, \@baz;
'
1
0
[download]

smartmatch:

perl -wE '
my @foo = (1, 2, 3);
my @bar = (1, 2, 3);
my @baz = (1, 2, 4);
say @foo ~~ @bar;
say @foo ~~ @baz;
'
Smartmatch is experimental at -e line 5.
Smartmatch is experimental at -e line 6.
1
[download]



The way forward always starts with a minimal test.