From @dmcbride

Created by @dmcbride

$ perl5.16.0 -E 'say "what?" if "a" ~~ 0'
what?

perlop says​:

Object Any invoke ~~ overloading on Object,
  or fall back to...

Any Num numeric equality
  like​: Any == Num
Num nummy[4] numeric equality
  like​: Num == nummy
undef Any check whether undefined
  like​: !defined(Any)
Any Any string equality
  like​: Any eq Any

I think the "Any Num" match should actually be​:

nummy[4] Num numeric equality
  like​: nummy == Num

I know there is reluctance to play with smart matching in general,
but this does seem like an oversight.

Ideally "nummy" would be defined as​:

Either an actual number, or a string that looks like one, B<or an object
that overrides ==>.

But that's probably asking a bit too much.

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.16.0:

Configured by nobody at Thu May 24 08:14:56 MDT 2012.

Summary of my perl5 (revision 5 version 16 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=3.2.12-gentoo, archname=x86_64-linux-thread-multi
    uname='linux naboo 3.2.12-gentoo #1 smp sun mar 25 15:59:37 mdt 2012 x86_64 intel(r) core(tm) i7 cpu 930 @ 2.80ghz genuineintel gnulinux '
    config_args='-desr -Duse64bitall -Dusethreads -Dprefix=/home/dmcbride/perl/5.16.0'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.5.3', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/../lib64 /usr/lib/../lib64 /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.14.1.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.14.1'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.16.0:
    /home/dmcbride/perl/5.16.0/lib/site_perl/5.16.0/x86_64-linux-thread-multi
    /home/dmcbride/perl/5.16.0/lib/site_perl/5.16.0
    /home/dmcbride/perl/5.16.0/lib/5.16.0/x86_64-linux-thread-multi
    /home/dmcbride/perl/5.16.0/lib/5.16.0
    .


Environment for perl 5.16.0:
    HOME=/home/dmcbride
    LANG=en_US.utf8
    LANGUAGE=
    LC_ALL=en_US.utf8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/dmcbride/bin:/usr/lib/distcc/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3:/usr/x86_64-pc-linux-gnu/i686-pc-linux-gnu/gcc-bin/4.5.3:/share/cvs/bin:/usr/local/bin:/usr/games/bin:/share/bin:/share/darin/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From zefram@fysh.org

Darin McBride wrote​:

$ perl5.16.0 -E 'say "what?" if "a" ~~ 0'
what?

That's as documented. By using a number on the RHS, you've asked for
a numerical comparison.

I know there is reluctance to play with smart matching in general,
but this does seem like an oversight.

No, it's deliberately avoiding unwanted complexity. It's consistent with
Perl's usual handling of strings in numeric contexts, and following the
general principle that the RHS of ~~ determines the type of comparison.

-zefram

The RT System itself - Status changed from 'new' to 'open'

From @dmcbride

On Sunday June 10 2012 5​:38​:01 AM you wrote​:

Darin McBride wrote​:

$ perl5.16.0 -E 'say "what?" if "a" ~~ 0'
what?

That's as documented. By using a number on the RHS, you've asked for
a numerical comparison.

I know it's as documented. I even provided said documentation. But it's
still a "say what?" scenario. This is definitely not DWIMmy.

I know there is reluctance to play with smart matching in general,
but this does seem like an oversight.

No, it's deliberately avoiding unwanted complexity. It's consistent with
Perl's usual handling of strings in numeric contexts, and following the
general principle that the RHS of ~~ determines the type of comparison.

"general principle"

Object Any invoke ~~ overloading on Object,
  or fall back to...

Nope.

Num nummy[4] numeric equality
  like​: Num == nummy

Nope.

undef Any check whether undefined
  like​: !defined(Any)

Nope.

In the "Other" section, there are 3 of 5 entries that rely on the LHS of ~~ to
determine the type of comparison. Even the rest of the sections show the LHS
determining the comparison (Any ~~ HASH being different than Regexp ~~ HASH).

So, if we had a new section​:

nummy​:

Left Right Description and pseudocode

nummy1[4] nummy2[4] numeric equality
  like​: nummy1 == nummy2
Any nummy[4] string equality
  like​: Any eq nummy

then we are still having the RHS "determine the type of comparsion" - at least
as much as we do for everything else.

I'm simply having a hard time imagining anyone *wanting* "a" ~~ 0 to match.
Wanting "a" == 0 to match is different only in being explicit about a numerical
comparison, but ~~ is supposed to be more DWIMmy than that.

As a side effect, it would clean up a surprise warning when attempting this
under warnings.

From @ap

* Darin McBride <dmcbride@​cpan.org> [2012-06-10 16​:15]​:

I'm simply having a hard time imagining anyone *wanting* "a" ~~ 0 to
match.

Maybe it’s easier if you realise that C<< '1 banana' ~~ 1 >> would also
have to fail. If you want that, are you sure you wanted ~~ and not eq?

From @dmcbride

On Sunday June 10 2012 7​:35​:35 PM you wrote​:

* Darin McBride <dmcbride@​cpan.org> [2012-06-10 16​:15]​:

I'm simply having a hard time imagining anyone *wanting* "a" ~~ 0 to
match.

Maybe it’s easier if you realise that C<< '1 banana' ~~ 1 >> would also
have to fail. If you want that, are you sure you wanted ~~ and not eq?

Ok, I have to admit, that seems odd, too. Then again, I run under full
warnings at all times, with FATAL enabled, too, just for proper masochism.

So I tried under common​::sense instead, didn't get the warning, and so I see
that others might prefer this.

I'm not sure if this is an argument in favour or against the change. But,
since warnings is part of core, and common​::sense isn't, I would have expected
~~ to "smartly" avoid the warnings.