Re^2: 5.10 smart match behaviour

Did you just say "list in scalar context"? There's no such thing! His sub is *not* returning a list.

Maybe you meant "the comma operator in scalar context", but that would presuppose that functions built by constant use the comma operator.

In fact, it appears that the comma operator is *not* used. Quote the docs (emphasis in original),

Note that constants with more than one value do not return their last value in scalar context as one might expect. They currently return the number of values, but this may change in the future. Do not use constants with multiple values in scalar context.

That means that X (as built by constant) returns 3 in scalar context for the current version of constant, and that you shouldn't count on that always being the case.

Comment on Re^2: 5.10 smart match behaviour Select or Download Code

Replies are listed 'Best First'.
Re^3: 5.10 smart match behaviour by Fletch (Bishop) on Jun 10, 2008 at 14:01 UTC
Oop, quite right. My constant stand-ins were using `qw//` directly which was behaving comma-like in imposed scalar context rather than passing through another layer (as happens with `constant` where the args get packaged up into an array and then turned into `sub () { @list }` which instead behaves like one would expect an array evaluated in scalar context imposed by the caller). More precise would have been "a sub whose return value is a list generated via `qw//` called in a scalar context", but that's not what he had due to how `constant` works now so he instead had "a sub whose return value is an array called in a scalar context". In either case they're both a single scalar value neither of which (`'c'` nor `3`) match. The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]
Re^3: 5.10 smart match behaviour by zgrim (Friar) on Jun 10, 2008 at 14:25 UTC
ikegami++, thanks for pointing out very clearly what the problem was, in terms of contexts. But as almut++ also pointed out, i'm still thinking it's more a matter of non-DWIM behaviour. You'd say, well, we've got warnings for that. :) One of the problems is, if these are equivalent (because of the context imposed on X): `perl -Mstrict -wE'use constant X => qw(a b c); say "ok" if "a" ~~ X'` [download] and `perl -Mstrict -wE'use constant X => qw(a b c); say "ok" if "a" == X'` [download] that smart match breaks the warning: Argument "a" isn't numeric in numeric eq (==) at -e line 1. We could at least work towards a fix for this, maybe ? -- `perl -MLWP::Simple -e'print$_[rand(split(q\|%%\n\|, get(q=http://cpan.org/misc/japh=)))]'` [download]	[reply] [d/l] [select]