I don't see how that is problematic.
Semantically, it is problematic because it is not possible the way things are at the moment; and if it is changed, it will break existing code -- which is p5p generally consider sacrosanct.
In my terminology, I'm only returning the value that was in that address -- so the compiler/interpreter can't assign a new value into the variable location.
Implementation wise, lvalue subs always return an lvalue. That's why any attempt to return a constant from an lvalue sub causes an error:
sub x :lvalue { 1 };;
[Can't modify constant item in lvalue subroutine return at (eval 18) l
+ine 1, near "1 }"
If that was allowed, then x() = 2; would modify that constant.
And even if you only returned an rvalue ("the value that was in that address") when you detected that you were called in an rvalue context -- were that possible -- then it would still break this code:
my $ref = \x(); ## lvalue context, no assignment.
... some time later assign through the ref taken.
$$ref = 'anything at all';
Currently, and since their inception, that has be both legal and useful.
For a change to be made such that returning an non-lvalue from an lvalue sub was (conditionally) possible; would break any existing code; and the expectation.
FWIW: I wish lvalue subs could inspect the value they are assigned; but I was told very firmly a long time ago that would never be possible; because any assignment happens after the sub returns, in the calling context, long after the sub is finished.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
Suck that fhit
|