Is it "inline assignment" or "prefix assignment"? I came up with the former but you used the latter. Is the latter the official term?
Which term should I use in tests and comments?
So we potentially need to be careful what functions we're talking about.
My solution doesn't change when save and restore is performed. It only changes how it's performed.
- Does implicitly make a local somehow violate "affect the current environment"?
- I don't want to be the sole deciding vote -- save/restore is the existing action.
I found a solution that doesn't require local parameters. It has the advantage that it also works for builtins (which don't have their own scope). Another advantage is that it pretty much doesn't change any existing behavior. It only changes things for references.
- There's probably an intersection with workers/55062 to be thought about.
- Are there other issues with prefix assignments to special parameters?
There is indeed an intersection with workers/55062. An inline assignment of a special parameter is doing about the same as a local redefinition. Both suffer from the same issues. My solution for inline assignments moves the specialness to the assigned instances of the parameters. Therefore, it makes sense to also move the specialness to localized parameters (rather than to temporarily move the special parameters to the local scope).
Tied parameters are a complicating factor for both, inline assignments and localized special parameters. For inline assignments, tied parameters in general, not just special ones, are problematic. I figured that things get much simpler by assuming that assigning/localizing one of the tied parameters also assigns/localizes the other one, which is similar to unsetting where unsetting one also unsets the other. This has the advantage that you never end up with 3 parameter instances (2 scalars and 1 array, or 1 scalar and 2 arrays) but always with pairs of 1 scalar and 1 array that can remain tied to each other.
Philippe