This was a change in how Perl parses things. The new rule is "if it looks like a function call, treat it as a function call" and it has to do with what to do when you have a an identifier followed by an open paren but with whitespace in between.
So the code: print ( $foo == 1 ) ? "hi" : "bye"; is now parsed as: print( $foo == 1 ) ? "hi" : "bye"; or, with an extra set of parens to make it clear: ( print( $foo == 1 ) ) ? "hi" : "bye";
It used to be that the first case was more ambiguous. Sorry, I don't recall the details. I think part of the original reason this was looked at was that "print (" was parsed differently than "print\n(", but I think there were other "interesting" cases. So this became one of the relatively few places where Perl chose consistancy over DWIM.
So you can "thwart" this case by putting some non-whitespace
between the identifier ("print") and the open paren. The
cases I showed of this were adding a "(" [and a matching
")"] or adding a "+". A long time ago uniary "-" was
made to work with barewords (not just numbers), primarilly
to support the argument passing syntax that came from
Python tcl when Tk was ported to Perl:
meth( -foo => "bar" );
The "-" is just prepended to the bareword giving use the
result of
meth( "-foo", "bar" );
for that code. Later, unary "+" was made to work with
just about anything as a way to give Perl hints about how
to parse things. In the case of unary "+", it is just
dropped completely (it doesn't even impose a scalar context
on its operand).
Update: Sorry for "blaming" the wrong language there at first.
- tye (but my friends call me +Tye)In reply to (tye)Re2: If / elses
by tye
in thread If / elses
by mbond
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |