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

Re: Deprecation of smartmatch

Thread Previous | Thread Next
From:
Martijn Lievaart
Date:
December 4, 2022 14:08
Subject:
Re: Deprecation of smartmatch
Message ID:
64828218-9d42-7347-a227-600fd62ca753@rtij.nl
[ resend, sent it to Paul instead of p5p, sorry Paul ]


Op 02-12-2022 om 18:38 schreef Paul "LeoNerd" Evans:

> * The `in` meta-operator
> https://metacpan.org/pod/Syntax::Operator::In
>
> One thing people liked to use `~~` for is to ask "is this value a
> member of that list of values?"; a sortof set-element-of operator.
> While it's been possible to ask this question using List::Util::any
> ever since perl 5.6 (and likely before - I don't remember that far
> back in time), people still aren't satisfied with that notation:
>
> if($x ~~ @numbers) { ... }
> if(any { $x == $_ } @numbers) { ... }
>
> For those folks, I have written an `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) { ... }


A thought occured to me of a possible problem here. Consider:

     $its_in = $needle in:=~ qr/haystack/;

v.s.

     $its_in = $needle in:< @haystack;

Wouldn't the first to be the RHS of the op, and the second the LHS? 
Wouldn't this create a problem? Or do I simply misunderstand?


M4




Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About