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

Re: disabling smartmatch and when()?

Thread Previous | Thread Next
Tomasz Konojacki
June 20, 2022 14:10
Re: disabling smartmatch and when()?
Message ID:
On Mon, 20 Jun 2022 14:45:48 +0100
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?

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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About