Re: [Language Design] Should inline assignments create local parameters?

On Sun, Aug 9, 2026 at 10:07 AM Philippe Altherr <[email protected]>
wrote:

>
> Local parameter
>
> Save and restore parameter
>
> A: var=v1 - ref=v0
>
> B: var=v2 - ref=v0
>
> C: var=v2 - ref=v3
>
> D: var=v3 - ref=v3
>
> A: var=v1 - ref=v1
>
> B: var=v2 - ref=v2
>
> C: var=v3 - ref=v3
>
> D: var=v0 - ref=v0
>
> \What do you think? Do you agree that the former implementation leads to a
> preferable/more intuitive behavior? Do you agree that we could change the
> implementation at the risk of changing the behavior of some existing
> scripts?
>

The 2024 POSIX spec (https://pubs.opengroup.org/onlinepubs/9799919799/
at 2.9.1.2 Variable Assignments) says (among rules not related to this
question)

   - If the command name is a standard utility implemented as a function
   (see XBD *4.25 Utility*
   <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_25>),
   the effect of variable assignments shall be as if the utility was not
   implemented as a function.
   - If the command name is a function that is not a standard utility
   implemented as a function, variable assignments shall affect the current
   execution environment during the execution of the function. *It is
   unspecified:* (my emphasis)
      - Whether or not the variable assignments persist after the
      completion of the function
      - Whether or not the variables gain the *export* attribute during the
      execution of the function
      - Whether or not *export* attributes gained as a result of the
      variable assignments persist after the completion of the function

So we potentially need to be careful what functions we're talking about.

Older versions of the spec said only "*if the command name is a special
built-in or function, variable assignments shall affect the current
execution environment."*  That would appear to correspond to a
determination of the first "unspecified" branch in the newer standard.  I
don't recall the context for the change in the newer language, but I
suspect zsh and other shells treated functions more like external commands
even before the spec change.  (There are stackexchange answers with updates
from a year ago that still assume the 10+ year old spec.)

I agree that the implementation with locals makes more sense in the context
of references.  I think sticking with "assignments do NOT persist" and
"variables DO gain the export attribute" probably assures that the
"assignments shall be as if the utility was not implemented as a function",
and results in the fewest differences for current scripts.

However:

   - 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.
   - There's probably an intersection with workers/55062 to be thought
   about.
   - Are there other issues with prefix assignments to special parameters?