On Wed, 7 Oct 2015 09:24:45 +0100 Dave Mitchell <davem@iabyn.com> wrote: > 3. when { FOO } has condition FOO. > > For example: > > use constant ANS => 42; > use constant ME => "davem"; > > when (undef) # equivalent to when { !defined($_) } > when (42) # equivalent to when { $_ == 42 } > when (ANS) # equivalent to when { $_ == 42 } > when (42.1) # equivalent to when { $_ == 42.1 } > when ("42") # equivalent to when { $_ eq "42" } > when ("davem") # equivalent to when { $_ eq "davem" } > when (ME) # equivalent to when { $_ eq "davem" } > when ($x) # equivalent to when { $_ eq $x } Some trickier cornercases 3a) dualvar constants: use Scalar::Util qw( dualvar ); use constant THREE => dualvar(3, "3"); when(THREE) # eq or == ? 3b) 'bigint' and friends: use bigint; when(5) # 5 is now a Math::BigInt instance surely? > Rationale: > > I think 95% of what people actually *want* a smartmatch system for is > so that they can write code of one of these three forms: <snip> Agree. > Since perl is about making easy things easy, I think that achieving > the above forms should be our basic goal. If we don't do that, we've > failed. Of course perl likes to make hard things possible too, but I > think that is an auxiliary consideration for now. Agree. > Why get rid of the smartmatch operator? I've never really seen the > point of it, apart from being something that exposes the underlying > mechanism of when(), c.f. readline() for <>. If we do keep it, then > it should have exactly the same semantics as I've described above for > when(). Then the condition for when(FOO) would be defined as always > exactly equivalent to when { $_ ~~ expr }. Agree doubly-so. I think a lot of people want a simple dispatch-on-constantish things switch-alike, and the idea of the very generic smartmatch came along accidentally from Perl 6. We don't strictly need it to get a switch-alike out of this given/when syntax, so it makes a lot of sense to consider it a separate operator, and work on given/when as their own standalone thing. > Finally, if the smartmatch operator were freed up, then maybe we could > repurpose it as some sort of recursive grep operator that searches > though nested arrays and hashes for something. That's just a vague > thought though. If we wanted a fancier recursive grep, surely that's more a candidate for some kind of function in a module of somesort (List::Util?) rather than really basic syntax using up an infix operator. Much easier to backport, too. > Finally finally, regardless of what semantics we finally choose, > perhaps we should use a new feature name for all this, e.g. > > use feature 'switch2'; > > with 'switch' becoming an error, so that existing code will noisily > fail to compile rather than failing mysteriously on subtle changes to > semantics. A new name could be good, yes. I'm not sure I like the specific "switch2" but now we're really bikeshedding... Maybe new keywords while we're at it? use feature 'dispatch'; dispatch($str) { on("hello") { say "Hello, there"; } on("bye") { say "Goodbye then"; } } -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANSThread Previous | Thread Next