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.

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.

I don't, that's why I only use it when I'm doing debugging/verification. I usually just comment out any such quick checks if not outright delete them in the end. It's mostly just a convenience for me to make sure data structures are the same before/after some code I change.

In all honesty, I probably would have skipped learning about it had I known it was "experimental", but I went ahead and read through the chapter of Learning Perl that covered Smart Match and Given-When (also experimental) without knowing that, and only found out when I went to do the exercises at the end. I've never had a reason occur to me as to where I would use given-when, but I have found Smart Match occasionally useful for quick and dirty (i.e. lazy one line) debugging. :-)

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