If I'm not mistaken, I believe that there's another issue you're trying to pull it here, namely difference between for(1) and for(1..3). They _do_ behave weirdly, I totally agree. But I believe that's a totally separate issue, probably related to parser even, because this code:
my $a = 2;
$_++ for 1..$a;
print "$a\n";
# 2
shows that $a is not aliased. Therefore I don't see how the original problem that needs a scalar be both aliased and read-only, is relevant here. | [reply] [Watch: Dir/Any] [d/l] [select] |
You seem to be operating from the point of view that "It's self-evident that literals should create non-modifiable values." Yet that's currently not the case in 50% of the examples I posted.
«1» in «for (1)» could return a non-modifiable value, but it intentionally returns a modifiable value (in a sense) some of the times.
«1..3» in «for (1..3)» could return non-modifiable values, but it returns modifiable values, and it's intentionally not getting changed because people want literals to return modifiable values.
It's not self-evident that literals should create non-modifiable values.
| [reply] [Watch: Dir/Any] [d/l] [select] |
Sorry, I didn't make myself clear. I do see that these values are modifiable. But my objection is that for(1..3) construct doesn't do aliasing, which is 50% of the original bug. If my example above did print 3 instead of 2, then yes, I'd accept that as a proof.
Same thing on $_++ for 1 - it dies, because of aliasing comes into play. And I neither get what does "intentionally returns a modifiable value (in a sense) some of the times" mean. For what I see, it just doesn't return a modifiable value, at all.
| [reply] [Watch: Dir/Any] [d/l] |