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

in reply to What is true and false in Perl?

The oft-cited list of values considered false is:

• undef
• 0
• ""
• "0"
• Any blessed objects that overload conversion to boolean to return false
• Empty lists and empty hashes

I did actually manage to find another value that Perl treats as false:

```-0.0

You can see its interesting behaviour here:

```perl -E'say(-0.0 eq 0?"eq 0":"ne 0"); say(-0.0?"true":"false");'
ne 0
false

Note that it's false but not (stringy) equal to zero.

This does vary between Perl versions. The behaviour documented above exists between Perl 5.6.x to 5.12.x (obviously you need to use print instead of say before Perl 5.10) and perhaps earlier. But in Perl 5.14.x, -0.0 is (stringy) equal to 0.

perl -E'sub Monkey::do{say\$_,for@_,do{(\$monkey=[caller(0)]->[3])=~s{::}{ }and\$monkey}}"Monkey say"->Monkey::do'

Replies are listed 'Best First'.
Re^2: What is true and false in Perl?
by Anonymous Monk on Oct 17, 2012 at 17:07 UTC
Another one that's false is a list of undefs. An array of undefs though is true.
```   if ( (undef,undef) ) { }   # a list of undefs is false

@arr = (undef,undef);
if ( @arr ) {}             # an array of undefs is true
We make use of this like so:
```   \$_ = 'x';
if ((\$a,\$b) = m/(.)(.)/) { }
mc0e

That's not quite true. Observe:

```# Does not say "true". This is as you describe.
say "true" if undef, undef;

# Still doesn't say true.
say "true" if 1, 2, 3, 4, undef;

The reason for this behaviour is that if imposes a scalar context on the expression that acts as its condition. When the comma operator is used in a scalar context it is not a list constructor and instead evaluates the left argument, discards it and then evaluates the right argument (it basically acts like the semicolon but with a different precedence).

Thus this:

```say "true" if 1, 2, 3, 4, undef;

Is essentially the same as:

```sub x {
1;
2;
3;
4;
return undef;
}
say "true" if x();
perl -E'sub Monkey::do{say\$_,for@_,do{(\$monkey=[caller(0)]->[3])=~s{::}{ }and\$monkey}}"Monkey say"->Monkey::do'

It isn't a list nor an array in scalar context that your example is making use of. It is a list assignment (in scalar context).

A list assignment in scalar context returns the number of items in the right-hand list.

And, in your example, 'x' =~ m/(.)(.)/, in a list context, returns an empty list, not a list of two 'undef's. An empty list (on the right-hand side of the list assignment) contains zero items so the assignment in scalar context returns 0, which is one of the documented false values.

But there is a kernel of truth hidden behind your mistakes.

There have been some exceptions (as near as I can remember, on an inconsistent basis) to the rule about what a list assignment returns in scalar context. Those exceptions were meant to handle cases very similar to what you described.

```sub undefs {
my( \$count ) = @_;
return ( undef ) x \$count;
}

if( my( \$x, \$y ) = undefs(2) ) {
print "true\n";
} else {
print "false\n";
}

In some versions of Perl, that code would print "false". In the relatively modern Perl I had handy, it prints "true".

I even recall having a very short on-line conversation with Larry years ago about what I considered to be bugs such as ( undef, undef )[0] being an empty list instead of being a list containing a single 'undef' and he was worried about breaking the fact that the above code was supposed to print "false". I argued that that wasn't a feature worth keeping.

But I didn't follow-up to see what decisions were made back then. And, just now, I didn't test the current behavior except minimally. I think there was at least one thread about this stuff on PerlMonks around the time Larry and I talked, but I haven't looked for it. It might've just been in the chatterbox.

- tye

Hi can somebody explain to me the reason behind the following: test.pl: #!/usr/bin/perl my \$a = (1==0); print "__".ref(\$a)."__\n"; Output: ____
```print "true" if "IS" eq "evaluates to in scalar context"; # doesn't pr
+int.