develooper Front page | perl.perl5.porters | Postings from August 2012

Re: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
Eirik Berg Hanssen
August 24, 2012 06:08
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
On Fri, Aug 24, 2012 at 2:32 PM, Jesse Luehrs <> wrote:

> Using a "looks like a number" check leads to silent and hard to detect
> bugs. For instance,
>   given ($foo) {
>       when ("a") { ... }
>       when ("b") { ... }
>       when ("0") { ... }
>       default    { ... }
>   }
If this checks for "looks like a number" and does something different, I
> might end up getting "0.0e10" or something accepted by the 'when ("0")'
> condition, when that's clearly not what I meant. This kind of unexpected
> and hard to detect behavior is one of the main things we're trying to
> get rid of with this new proposal.

 If that's not what you meant, why did you write that?

  Why not SWYM:

  given ($foo) {
      when ("a") { ... }
      when ("b") { ... }
      when { $_ eq "0" } { ... }
      default    { ... }

    If smart matching checks if some value (like an object) can be used as
a regex (or coderef), and if so, is matched against as a regex (or
coderef), even though it also has a string representation, why not also
check if it can be used as a number?

  Only because use of overload::constant to create objects with overloading
other than num, string, boolean and arithmetic is not very common?  Or
because they are SEP?  (In the presence of such, C<< when ("a") >> may end
up matching against ~~-ol, &{}-ol, or qr//-ol, so it is could still lead to
silently and hard-to-detect bugs.)

> I'm starting to think that only allowing string matching (as in the
> initial proposal) is going to be the only sane option here/: It's not
> like numeric matching would be all that much harder even with that form:
> '$thing ~~ sub { $_[0] == 2 }' or 'when { $_ == 2 } { ... }'.

  That would still be sane, but it would mean Abigail's case of C<< when
($x) >>, where $x could be either a regex or a number, still could not be
handled by smart matching:

  For regexen, C<< when { $_ == $x } >> will fail as bad as C<< when ( 0+$x
) >>.

  Sacrificing smartness and ambiguity for the numerical case, but retaining
both for the coderef, regex, and string cases ...


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About