Front page | perl.perl5.porters |
Postings from December 2022
Re: Deprecation of smartmatch
Thread Previous
|
Thread Next
From:
Darren Duncan
Date:
December 2, 2022 20:12
Subject:
Re: Deprecation of smartmatch
Message ID:
29191f98-92f0-0cda-f7bc-4ffb59892d1e@darrenduncan.net
On 2022-12-02 9:38 a.m., Paul "LeoNerd" Evans wrote:
> ... new pair of
> keywords used in a similar style to given/when ... use an operator
> that the programmer specified upfront. That way, there can be no
> surprises that it does "odd things" when it encounters some weird
> value you weren't expecting. If you expected string equality
> matching, you *know* you are getting string equality matching
> because it says so right there:
>
> my $var = "abc";
> match($var : eq) {
> case("abc") { $ok++ }
> case("def") { fail('Not this one sorry'); }
> }
I agree fully that this is the right way to go.
I would further say that it must be mandatory for the programmer to specify the
comparison operator to use. There must not be an implicit default for leaving
that out, because this would be full of surprises, saving a few characters isn't
worth the ambiguity.
I will also add that this construct must be generalized enough to support
anonymous inline defined operators such as map/grep/sort/etc do with their block
syntaxes, and that this is not limited to things for which an infix operator
syntax exists.
One can bikeshed the exact syntax.
> ... a sortof set-element-of operator ... `in` meta-operator. Motivated in
> much the same way as match/case above, there can be no ambiguity on
> "is this matching with number or string equality here?" because it
> says right upfront in the operator name itself. You tell it - `==`
> or `eq`.
>
> if($x in:== @numbers) { ... }
I also like this idea, especially the programmer-defined operator to use. And
everything I said about mandatoryness and anonymous operators applies here too.
But in contrast to the switch-case type expression above, this list membership
thing may be best to remain a module without dedicated language syntax, because
there are many variations or list operations that it would be good to have that
flexibility with, and it would be hard to pick a good set for core, and special
syntax doesn't really add much over List::Util etc, or maybe such syntax should
be a List::Util enhancement instead.
> ... `equ` and `===`, which
> are slight variants of the familiar `eq` and `==` but which consider
> undef to be a distinct value separate from empty or zero.
>
> if($n === 0) { say "n is zero" }
> else { say "n is undefined, or non-zero" }
>
> Useful on their own perhaps, but they become more useful when you
> realise you can use them with `match` or `in`:
I agree that having these undef-distinguishing variants would be a very good
thing to have in core contemporary to `eq` and `==`. One might bikeshed on
their syntax, but in principle taking the existing operator names and adding 1
character for the variant seems to be an elegant choice.
So in summary, I agree with the match-case and eqv/=== additions to core, but I
feel the "in" should be left for the likes of List::Util. The first 2 have a
high win for core syntax AND they are relatively uncomplicated, while the last 1
is a lot more complicated in its variants and best left in modules, albeit
possibly core-bundled modules.
-- Darren Duncan
Thread Previous
|
Thread Next