Re: LOCAL_VARS option ?

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Thu, 19 Jan 2017 07:47:53 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > Phil suggested on IRC a LOCAL_VARS option that has the effect of making
> > all newly-declared variables local
>
> I believe we discussed this idea once before, and rejected it on several
> grounds.  However, I can't find the thread at the moment.  From memory:
> 
> 1. Once the option is set, it affects all functions called by (whether
>    directly or indirectly) the one that set the option.  If set at the
>    top level, this results in a significant change in semantics.

I suspect we'd even need "emulate -L zsh" to *un*set the option to
restore sanity.  Otherwise you're not emulating native zsh variable
semantics.

There's some prior art for resetting options at each function level, but
it's another icky complexity.

> 2. Unlike local_options, which applies when the function exits, this has
>    to be applied when the parameter is created.  There's already a
>    mechanism to accomplish this, namely to declare the parameter.  The
>    only reason to need local_vars is to change the semantics of *other*
>    functions [see (1)], which is generally a bad idea.

Hmmm... I suspect people would want to set it to protect their own
functions, rather than randomly assume what other functions they have
are or are not doing with variable scoping, which would be a bad thing
to assume.  But other people's functions are likely to get caught in
the crossfire anyway.
 
> 3. If unset by a called function in order to prevent (2) and that called
>    function is NOT also using local_options, it can break the calling
>    function in unpredictable ways.

I think that mostly means the way to turn this off (other than
implicitly at each level) would be

setopt localvars localoptions

but if you have some reason for unsetting localoptions you are stuck.

> 4. The semantics of the other LOCAL_* options are already problematic in
>    obscure ways, but just because we're stuck with them doesn't mean we
>    should add another potentially problematic variation.

Well, the *reason* for adding them is a bit of extra safety, rather than
creating problems as side-effects...  but I agree about the potential
problems.  In fact, my best argument against this probably is the
knock-on effects of everything that has to be made consistent, which
I think is hard to foresee, and the variable code is famously
complicated already.

> 5. (New since the last time this was discussed) The type of problem this
>    "solves" is generally better addressed by WARN_CREATE_GLOBAL so that
>    proper use of parameter declarations can be applied.

Yes, that makes a difference, but it doesn't detect the case where you
re-use a variable in a nested function without redeclaring it.  (That
can be done, too, by comparing variable levels, but it's a significantly
more intrusive option --- consider the completion system.)

pws