Front page | perl.perl5.porters |
Postings from June 2022
Re: disabling smartmatch and when()?
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
June 20, 2022 16:58
Subject:
Re: disabling smartmatch and when()?
Message ID:
YrCnMivqVy3AcSH0@iabyn.com
On Mon, Jun 20, 2022 at 05:54:52PM +0200, Tomasz Konojacki wrote:
> On Mon, 20 Jun 2022 15:43:44 +0100
> Dave Mitchell <davem@iabyn.com> wrote:
>
> > It's gone through a 9 year deprecation cycle, with a mandatory
> > experimental warning that you have to explicitly disable.
>
> So signatures were deprecated too? "Experimental" doesn't mean
> deprecated. If we want smartmatch to be deprecated, then we should
> deprecate it. We should have done that a long time ago, instead of
> pretending that signatures/try/isa/whatever have the same status as
> smartmatch.
>
> Smartmatch was made "experimental" retroactively and for a large portion
> of our users the warnings started appearing as late as 10 years after it
> was introduced!
Smartmatch was introduced in 2007 5.10.0).
It's behaviour was radically changed in 2009 (5.10.1/5.12.0).
It started having a mandatory warning in 2013 (5.18.0).
> RHEL6: released in 2010, supported until 2020: perl 5.10 (no warnings)
> RHEL7: released in 2014, supported until 2024: perl 5.16 (no warnings)
> RHEL8: released in 2019, supported until 2029: perl 5.26 (warns)
RHEL is hardly a relevant comparison. It is an extremely conservative
linux server distribution whose software is usually years out of date.
Virtually no one will have *developed* (as opposed to *deployed*) perl
code on RHEL. People who write CPAN modules won't have developed it on
RHEL, and even if they originally developed it on <= 5.16.0 it's unlikely
that they never tried it on any later perl (apart from abandoned modules),
nor ignored all the cpantesters reports.
> Not to mention that the "experimental" warning doesn't even attempt to
> inform the user what it means:
>
> > perl -E '$z ~~ $b'
> Smartmatch is experimental at -e line 1.
If I were to start coding in python or rust or something, and when I first
used a feature it spat out a warning about it being experimental, I would
exhibit some degree of caution.
> Our documentation isn't much better. The meaning of "experimental" is
> hidden deep in perlpolicy. There is no *loud and clear* warning in e.g.
> the smartmatch section of perlop.
perlop's entry for smartmatch says (and has since 5.20.0), in the first
paragraph:
The smartmatch operator is L<experimental|perlpolicy/experimental> and
its behavior is subject to change.
So, it warns coders that their code may break on future perl releases, and
directs them to the perlpolicy section on experimentalness, which says in
the first sentence:
If something in the Perl core is marked as B<experimental>, we may
change its behaviour, deprecate or remove it without notice
Note the "remove without notice".
Similarly in perlsyn, there is this:
=head2 Switch Statements
....
Exactly what the I<EXPR> argument to C<when> does is hard to describe
precisely
...
The rules are far too difficult to understand to be described here.
See L</"Experimental Details on given and when"> later on
....
=head2 Experimental Details on given and when
As previously mentioned, the "switch" feature is considered highly
experimental; it is subject to change with little notice. In particular,
C<when> has tricky behaviours that are expected to change to become less
tricky in the future.
> I can't count the times I had to explain to people outside of the p5p
> bubble that "experimental" in the case of smartmatch actually means
> "deprecated" and they shouldn't use it.
Perhaps these people have no business being coders?
> The result of the above is that half of CPAN relies on smartmatch:
>
> https://grep.cpanauthors.org/search?q=%7E%7E+OR+%22given+%28%22+OR+%22given%28%22
>
> And that is just CPAN, there's certainly a lot of it in darkpan code too.
Good grief! Many of those are false positives, but people do seem to be
using it with gay abandon. That's a problem, certainly.
> The worst part is that we can't just say "use <X> instead" because there
> is no direct replacement for smartmatch and given/when! For each of the
> affected modules you have to analyse the code and figure out which one
> of the bajillion smartmatch comparison modes was being triggered and
> then you have to replace it with something verbose and ugly (e.g.
> List::Util::any or if/else-chain), which BTW, is not a good look for
> Perl at all.
At least if we remove smartmatch/when completely they'll *know* their code
needs fixing. If we just change its behaviour, we could silently break
their code - often in hard-to-detect edge cases. For example, their
module may continue to fine 99.9% of the time, till someone passes an
overloaded object to one of the module's methods and it suddenly breaks.
Perhaps we should add a new mandatory deprecated warning in addition to
the experimental warning, then remove smartmatch in 3 or so releases time?
PS - I would hazard a guess that the vast bulk of ~~ uses on CPAN can be
replaced with grep or similar, and that most uses of give/when can be
replaced with a chain of if/elsif/else. I suspect that very few places
make use of the recursive smartmatch feature.
In conclusion:
1) we can't do nothing, and the longer we leave it the worse it gets.
2) I think it is better to have a break where smartmatch/when() is a
compile-time error for a few releases before introducing a new smartmatch
with radically different behaviour, rather than just switching to the new
behaviour with no gap.
3) I am not opposed to a further deprecation cycle (possibly with a new
mandatory warning), before we disable it.
--
Standards (n). Battle insignia or tribal totems.
Thread Previous
|
Thread Next