Wrong behavior of the implicit smart operator in the given/when blocks

[Anonymous Monk]

I have the following code:

use 5.010;

my %hash = (a => 1);

given(\%hash){           # first true
#given('a'){             # all true
    when('a' ~~ $_){
        say "explicit ~~";
        continue;
    }
    when($_ ~~ 'a'){
        say "reversed explicit ~~";
        continue;
    }
    when('a'){
        say "implicit ~~";
    }
}

It is known that 'key' ~~ \%hash returns true if 'key' exists in %hash.

From the above code, when('a'){...} should return true because the key 'a' exists in %hash.

I see this as a perl bug. - Please correct me if I'm wrong.

My solution is when('a'){...} to be equivalent with when('a' ~~ $_){...}.
(In perl v5.14.2, it is equivalent with when($_ ~~ 'a'){...} - which in this case is wrong

[ikegami]

The docs say:

when($foo)

is exactly equivalent to

when($_ ~~ $foo)

Not when ($foo ~~ $_). The value passed to given is the thing being checked. In your example, the first case matches because your string matches your hash, but the next two fail because your hash doesn't match your string.

[educated_foo]

Smart match and given/when are horribly complex and confusing (see "Smart matching in detail" in perlsyn), with the semantics changing between versions. AFAICT they may even change again in some future Perl, as many people on perl5-porters think they're broken. I'd just stick to "exists $hash{a}", which is not much more to type, and works.

[ikegami]

Specifically, they think the interface is some combination of too confusing, too complex, too error prone. Smart::Match is seen as way better interface.

[tobyink]

As I understand it, it's DOY's smartmatch which is the possible candidate for future Perls. This pushes the behaviour of smart match out to modules (on a lexically scoped basis). So you can:

use smartmatch 'acme';

And then the ~~ operator will start acting along the lines of whatever's defined in the smartmatch::engine::acme module. Perl will then come bundled with a backwards compatible behaviour (modelled on 5.14 most probably) and a simplified one.

Personally, I tend to follow the rule of keeping the left hand side of the smart match as either a non-reference scalar or a blessed object. If you stick to that, then whatever you put on the right hand side, smart match generally behaves pretty sanely and intuitively. (With the possible exception of when you've got hashref on the right hand side - I'm not sure there's any completely intuitive behaviour in that case, but the current behaviour certainly seems no worse than anything else.)