I've become persuaded that the current behavior should be kept. It is deducible from operator precedence and, once known, is not the cause of any great confusion.
What will be the effect of the proposed 'fix' on constructions like this?
Will the compiler keep the old value from the index? Does the associativity of assignment change? How is prefix() to know whether it is in lvalue position in a call? Any such change needs to try these things.{ my $foo = 'ABC-2N322-850103'; sub prefix () :lvalue { substr $foo, 0, index( $foo, '-') } }
Update: Actually, the code above has a surprise in it, anyway. The result of the index call is kept instead of evaluated a second time:
{ my $foo = 'ABC-2N322-850103'; sub prefix () :lvalue { substr $foo, 0, index( $foo, '-') } sub foo () { $foo } } print foo, $/; my $bar = prefix = 'DEFG'; print $bar, $/ print foo, $/; __END__ output: ABC-2N322-850103 DEF DEFG-2N322-850103
After Compline,
Zaxo
In reply to Re: lvalue substring oddities
by Zaxo
in thread lvalue substring oddities
by ysth
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |