Yes, it looks at the string. Like you said, it can't look at the number part or:

my $val= "0 ";
my $dummy= 0+$val;
print "True\n"   if  $val;
[download]

would print "True". This is recorded in the source code in at least 4 places (for speed reasons). Each version boils down to these tests, in order:

1. undef is false
2. (references are true unless they reference a destroyed thing)
3. strings are false if-and-only-if they are "" or "0"
4. integers are false if-and-only-if they are 0 (zero)
5. reals are false if-and-only-if they are 0.0 (zero)

That second item is in parens because it only occurs in one copy of this algorithm. It doesn't matter much because I think the only way to get a reference to a destroyed item is during "global destruction".

But it did make me curious about a possible low-impact bug which turned out to not exist because of something more interesting: Every time you use a reference in a string context, the resulting string is reconstructed from scratch. When you use a number in a string context, the string representation of that number is computed and then cached inside the scalar so future uses of that (formerly number-only) scalar in a string context don't have to repeat that work. This optimization is not applied to references.

        - tye (but my friends call me "Tye")