Huh? Well, we know that
my ( $c, $d );
1 ? $c : $d = 'Hi';
is the same (to
B::Deparse) as
my ( $c, $d );
$c = 'Hi';
but what if you don't want to declare the variables in advance? Well,
my $d;
1 ? my $c : $d = 'Hi';
is the same as
my $d;
my $c = 'Hi';
In the other direction, here's a
strict-safe program that
B::Deparse makes non-
strict-safe:
$ perl -MO=Deparse -e 'my $c; 1 ? $c : my $d; $d'
my $c;
$c;
$d;
-e syntax OK
*. How about if we declare
both variables in the conditional?
$ 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.
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?
UPDATE: * Notice that B::Deparse changes the semantics here (but I guess there's always the disclaimer that that might happen). For example,
our $d = 'Out';
{
1 ? 0 : my $d;
$d = 'In';
}
say $d;
prints Out, but is converted by B::Deparse into
our $d = 'Out';
{
'???';
$d = 'In';
}
say $d;
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?