Not really. X() does not look the same as ${X()}. Having a function that returns a reference to a scalar is something unusual and that can't even be made to look "vanilla" in the calling code.
Returning the same reference to the same scalar but (hopefully) having different values each time is fundamentally a broken design.
Perl mostly makes copies of things but there are no shortage of places where Perl keeps aliases to things. So, Perl making a copy soon enough can save one from such a broken design in a lot of cases. Such may even convince one that the design is not so horrible. But it isn't hard to come up with ways to use such a broken thing where the copying doesn't happen fast enough.
One could certainly prefer a language where copying is always done. That certainly has merits.
And this is certainly not just an "undefined order of operations" problem. But, yes, exactly when the copying happens is a subtle interplay of a bunch of things, many of which are subject to optimization and/or the result of previous optimizations.
Trying to exactly specify the precise order of such subtle "operations" looks like a fool's errand to me (I don't think anybody would ever succeed). Doing so would also certainly prevent the possibility of most optimizations.
Note that the important "operation" here is the copying of a scalar which is not even an operation explicitly called out in the code. It is a implementation detail of string concatenation (which is also not explicitly coded).
Not that I expect you to agree with any of that. I didn't reply for your benefit.
- tye
In reply to Re^3: Order of evaluation/interpolation of references (op order)
by tye
in thread Order of evaluation/interpolation of references
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |