Re^2: weird error message in middle-aged-perl(5.14)

[AnomalousMonk]

Running the following program under ActiveState 5.8.9 and Strawberries 5.10/12/14 (all Win32) gives me identical results:

c:\@Work\Perl>perl -wMstrict -le
"my $x = 0;
 my $y;
 ;;
 sub S :lvalue { if ($x) { $y; } }
 ;;
 S() = 'foo';
 ;;
 print qq{x '$x'  y '$y'};
"
Can't modify logical and (&&) in lvalue subroutine return at -e line 1
+, near "} }"
Execution of -e aborted due to compilation errors.

Given the experimental nature of  :lvalue trumpeted in the Lvalue subroutines section of perlsub, I would be very reluctant to use it with a complex subroutine. If the Perl compiler can't even figure out the simple example code above, what hope for the vipers' nest of conditionals that is the  _Var() workhorse?

(Somewhere in the back of my mind is something about the compiler sometimes optimizing a statement like
    if ($x) { do_this(); };
to
    $x && do_this();
so this may be part of the problem — but don't quote me on this!
Update: Actually, it's  $y if $x; that is so optimized/compiled, using and not &&. Nevermind...)

[perl-diddler]

Given the experimental nature of :lvalue trumpeted in the Lvalue subroutines section of perlsub, I would be very reluctant to use it with a complex subroutine. If the Perl compiler can't even figure out the simple example code above, what hope for the vipers' nest of conditionals that is the _Var() workhorse?

Point taken -- but to it's credit, _Var was around for a few years BEFORE I added lvalue... i.e. I'd use it:

...(skipping prologue)

my $p=main->SUPER::new({scalar=>1, arr=>[1,2,3,4], 
                        hsh=>{one=>1, two=>2, three=>3}});
#w/o lvalue:

$p->scalar($p->scalar+1);
$p->arr(1,22);
$p->arr(3,$p->arr(3)+$p->arr(1));
$p->hsh("two",22);
$p->hsh("total", $p->hsh("one")+$p->hsh("two"));
P "arr=%s", [$p->arr];
P "hsh=%s", $p->hsh;

    Vs. w/lvalue:
$p=$p->SUPER::new({arr=>[1,2,3,4], hsh=>{one=>1, two=>2, three=>3}});


++$p->value;  #or ($p->value++;)
$p->arr(1)  = 22;
$p->arr(3) += $p->arr(1);
$p->hsh("two") = 22;
$p->hsh("total") = $p->hsh("one")+$p->hsh("two");
P "arr=%s", [$p->arr];
P "hsh=%s", $p->hsh;

#both give same results:

arr=[1, 22, 3, 26]
hsh={one=>1, three=>3, total=>23, two=>22}
arr=[1, 22, 3, 26]
hsh={one=>1, three=>3, total=>23, two=>22}

For data that doesn't need runtime checking -- just dynamic allocation in a structure, the lvalue'd versions work great and are considerably less visual 'mess' to use, BUT, as you mention, experimental means semi-worthless for production code. As it is, I tend toward using the non-lvalue form in about 2/3rd of new *assignments*. But when you do a read-modify-write, the lvalue form is awfully tempting.

Gonna go poke at the return vals as suggested by Athanasius and see if that clears up the error...