After reading Conditional Operator, and delighting in the potential for unreadable code coming from using a conditional operator as an lvalue, I wondered how far in advance the lvalues have to be declared.
Huh? Well, we know that
is the same (to B::Deparse) asmy ( $c, $d ); 1 ? $c : $d = 'Hi';
but what if you don't want to declare the variables in advance? Well,my ( $c, $d ); $c = 'Hi';
is the same asmy $d; 1 ? my $c : $d = 'Hi';
In the other direction, here's a strict-safe program that B::Deparse makes non-strict-safe:my $d; my $c = 'Hi';
*. How about if we declare both variables in the conditional?$ perl -MO=Deparse -e 'my $c; 1 ? $c : my $d; $d' my $c; $c; $d; -e syntax OK
Now, maybe there's some reason that parsing : my $d as an attribute list is good, or at least expected; but I can't see why 1 ? my $c : my $d would be parsed that way, but 1 ? my $c : $d wouldn't. Would somemonk enlighten me?$ perl -e '1 ? my $c : my $d' Invalid separator character '$' in attribute list at -e line 1, near " +$c : my " Execution of -e aborted due to compilation errors.
UPDATE: * Notice that B::Deparse changes the semantics here (but I guess there's always the disclaimer that that might happen). For example,
prints Out, but is converted by B::Deparse into
which prints In.
UPDATE: Oh, maybe it's that a colon followed by whitespace and an alphanumeric is always interpreted as the beginning of an attribute list, even if we're waiting for the interstitial colon of a conditional operator. Is this correct? If so, is it the desired behaviour? If so, should the precedence table in perlop be changed to reflect it?
In reply to Unexpected parsing by JadeNB
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |