Re: Should (undef ~~ 0) be true? (was Re: pjf: dual life modules)

G'day Rafael,

Rafael Garcia-Suarez wrote:

>>        undef ~~ 0                      # True
>> undef ~~ [0] # False!
>
> That's an inconsistency, and therefore a bug.

Oh good.

> I think that for backward compatibility sake, and possibly for undef
> commutativity sake, we should make undef ~~ 0 / "" not match. I'll do it
> as soon as possible.

Thank-you very much!  I've just rebuild blead, and it looks like now I don't
need to change any of the pod_examples.t tests at all.  New autodie patches
coming soon.

>> [undef] ~~ undef # True (currently false!)

> There, I don't get you. How can an array (a non-empty array) match undef ?
> The other cases I agree with.

Sorry, this is my 5.10.0 brain not fully grokking the new smart-match.  I
look at `[undef] ~~ undef` and think, "Aha!  We must go searching for undef
inside that array."

Of course, ~~ is no longer commutative, but I keep having a really hard time
forgetting that.  Moritz said I should try a strong drink, or a gold brick
wrapped around a lemon, but unfortunately I'm all out of Arcturan Mega-gin.

> Don't be sorry. You're one of the about 2 people who gave real-life,
> valuable and argumented feedback before 5.10.1 is out.

This actually has me worried.  I've been picking at smart-match when it's
intersected with me doing something with autodie, and I've done this purely
out of laziness; I don't want to have to change how autodie works.  I
haven't poked around with the rest of smart-match, although I promised I would.

So, to help fix that, I've written (as I think I promised to long ago), a
test case to find any surprises.  It's based upon the smart-match Perl tip
at http://perltraining.com.au/tips/2008-04-18.html . I'll send it as a
patch in a separate e-mail.  Currently, it gives me two surprises:

my @foo = qw(x y z xyzzy ninja);
 ok( @foo ~~ 'ninja' );  # Fails

my $array_ref = [5, 10, 15];
ok ( $array_ref ~~ 10 ); # Fails

Looking down the table in blead/perlsyn.pod, I see the first one has a
string on the RHS, and the RHS determines what we do.  It looks like that
falls through to the very last rule (Any/Any), which means we're doing
string equality.  That doesn't seem very useful; because unless we've
specially crafted our string, it's never going to be true.

The same seems to apply for the second one.  I assume we're triggering
Any/Num, which is doing a straight numerical equality.  Again, that doesn't
seem very useful.

If that's what really what these are triggering, then can I respectfully
suggest they're changed to search the list instead (as they would do if they
were reversed)?

All the best,

Paul