http://qs321.pair.com?node_id=1089622

If we had to live with only having string compare on scalar values, it could be worked around by nesting given with in the default clause of another given:

```given (+ \$x) {
when (+ \$n) { ... }
when (+ \$m) { ... }
default { given (\$x) { ... } }

But, having dug in to Perl Guts more than I should have, I think that disallowing tied (and probably other magic) variables on the RHS, a built-in smart match would be able to reliably determine if the RHS is a number.

• Comment on Re^2: Bring back the smartmatch operator (but with sane semantics this time)!

Replies are listed 'Best First'.
Re^3: Bring back the smartmatch operator (but with sane semantics this time)!
by moritz (Cardinal) on Jun 12, 2014 at 09:45 UTC
But, having dug in to Perl Guts more than I should have, I think that disallowing tied (and probably other magic) variables on the RHS, a built-in smart match would be able to reliably determine if the RHS is a number.

The problem is that Perl doesn't expose the concept "this scalar is a number" to the user (by design). Thus making a decision based on whether a scalar is a number is nearly always wrong.

A piece of code that already makes such a decision is the code that decides whether to warn on a numeric operation:

```\$ perl -wE 'say 0 + "1.2"'
1.2
\$ perl -wE 'say 0 + "1.2.3"'
Argument "1.2.3" isn't numeric in addition (+) at -e line 1.
1.2

So, what do I keep complaining about? A real problem are dual vars. Those aren't just a rare corner case that should be avoided, but for example the result from boolean operators:

```\$ perl -wE 'say 0 + !1' # no warning
0
\$ perl -wE 'my \$false = !1; say "<<\$false>>"' # empty string!
<<>>