develooper Front page | perl.perl5.porters | Postings from June 2022

Re: disabling smartmatch and when()?

Thread Previous | Thread Next
Leon Timmermans
June 21, 2022 11:42
Re: disabling smartmatch and when()?
Message ID:
On Mon, Jun 20, 2022 at 3:46 PM Dave Mitchell <> 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?

What if we delegate this to a module instead? Once we have Paul's infix
operator branch we can support about 95% of it outside of core. The
statement modifier form of when is the only problem and TBH that fallout
may be very limited.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About