/msg tye Sorry. I forgot how to.
It sounds like your arguing for defining the execution order?
If so, (apart from that I doubt it will ever happen), then I'd have to argue for the right-hand side of the = always being fully evaluated before the left-hand side is even considered, with the exception of context.
Now I realise that there is some precedent for at least partially evaluating the left-hand side with split.
makes good use of this to avoid a lot of work and memory.( $one, $two, $three ) == split '', huge_megabyte_scalar;
But if it is
$#a = 10; @a = split'', $huge_long scalar;
that doesn't (and couldn't) limit the split.
In the first case, the knowledge of the left-hand side used in evaluating the right-hand side is purely an optimisation--effectively, extended context--which doesn't change the semantic outcome of the statement. Only the performance.
In the case of
@hash{ listGenerator() } = ....;
pre-determining the affected slice of the hash prior to evaluating the right-hand side of the assignment can distinctly change the semantics which I think will always be a bad thing.
While I'd prefer clearly defined orders of evaluation, if it happened, then the right-hand side of assignment should always be (fully) evaluated before the left-hand side, except for those rare semantically benign situations where extend contextual information results in transparent optimisations.
Any situation where predetermined context or sub evaluation could actually determine the outcome of the statement, as would be the case if the range expression in
@hash{ 1 .. keys %hash } = delete @hash{ listGenerator() };
was done prior to the delete, would be a nightmare.
In reply to Re^4: re-key a hash (not so clear)
by BrowserUk
in thread re-key a hash
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |