I'd document it pretty much as I already described it. Passing a read-only value or a literal constant to something that makes aliases (for, a sub) may decide to make an alias to the read-only value or may decide to make a copy of it. The decision might even be different in those two case (a literal constant vs. some other read-only scalar). The choice is a matter of optimization and subtle edge cases and Perl code should not depend on either specific behavior. Both behaviors have existed in many different versions of Perl.
No, I don't consider it a bug that some versions of Perl don't die in the face of:
sub add1 { return ++$_[0]; } my $two= add1(1);
Despite the use of "++" over "1+" there being questionable. It does have the interesting and perhaps useful side effect of allowing: add1($count). Yes, it is a contrived example. As is yours.
I don't find it hard to imagine cases where either result would be preferred. I do find it hard to imagine cases where either result is a serious problem that I wouldn't just address with a better interface for the subroutine.
- tye
In reply to Re^3: ref to read-only alias ... why? (notabug)
by tye
in thread ref to read-only alias ... why?
by dk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |