Front page | perl.perl5.porters |
Postings from June 2022
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.Thread Previous | Thread Next