Front page | perl.perl5.porters |
Postings from June 2022
Re: disabling smartmatch and when()?
Thread Previous
|
Thread Next
From:
Dan Book
Date:
June 20, 2022 18:23
Subject:
Re: disabling smartmatch and when()?
Message ID:
CABMkAVV69_w8=J_k3FwhO8KzJWpX5hEFAeML_7KK921YRnHcXg@mail.gmail.com
On Mon, Jun 20, 2022 at 10:10 AM Tomasz Konojacki <me@xenu.pl> wrote:
> On Mon, 20 Jun 2022 14:45:48 +0100
> Dave Mitchell <davem@iabyn.com> wrote:
>
> > So...
> >
> > A while back, we collectively agreed that the smartmatch operator
> > and the when() keyword (which sometimes uses smartmatch under the hood),
> > had fundamental design flaws, and we retrospectively made
> > ~~/given/when/break experimental in 5.18.0 (nine years ago!).
> >
> > Since then we have failed to reach a consensus as to how these should be
> > fixed, or indeed whether they should removed altogether. This is an
> > unhappy state of affairs.
> >
> > I propose that right now (so appearing in 5.38.0), we disable C<~~> and
> > when(), and possibly C<given> and C<break> too. Any attempt to use them
> > will give a meaningful compile-time error (as opposed to a plain syntax
> > error).
> >
> > This will provide two positive outcomes. First, it will force users to
> > stop using it. Second, it provides an air-gap for if and when we
> introduce
> > the new and improved smart-match operator - i.e. rather the behaviour
> just
> > changing in one release, there is a clear demarcation between the old and
> > new behaviour, with people who test their new code on old releases
> getting
> > a clear signal, in that their code won't even compile on 5.38 ..5.44 say.
> >
> > Important note: please, PLEASE, don't turn this thread into yet another
> > discussion on how to revamp smartmatch: if you want to discuss that,
> > start a new thread (and read all the old threads about it first). This
> > thread is purely to discuss whether and how to disable smartmatch until
> > something better comes along (which could in theory be included in 5.38
> if
> > the other hypothetical thread bears fruit).
> >
> > So I think that at a minimum, the use of C<~~> and <when() should give
> > meaningful compile-time errors. The main issue is whether we should also
> > disable C<given> and C<break> too. Also, whether 'C<use feature 'switch'>
> > should be an error or warning too.
> >
> > Any opinions?
>
> I'm not sure what exactly you are proposing.
>
> If it's turning ~~ into an enabled by default feature flag (although
> disabled in the ":5.38" bundle) à la "indirect", then +1 from me.
>
> If you actually want to remove it, then I'm *strongly* opposed. We can't
> remove smartmatch until we provide a replacement *and* it goes through a
> proper deprecation cycle (and by "proper" I mean much longer than the
> usual 2 release cycles).
>
> Smartmatch is *very* widely used in production code and we *completely*
> failed
> to communicate that it's on its way out.
>
+1
We have no business removing smartmatch functionality without either a
feature flag or an extremely long deprecation period *and* replacement
functionality (and the proposed match feature is only one half of the
required replacement, the other being "in" as LeoNerd has also proposed).
-Dan
Thread Previous
|
Thread Next