Re: LOCAL_VARS option ?

[Bart Schaefer <schaefer@brasslantern.com>]

On Thu, 19 Jan 2017, Daniel Shahaf wrote:

> Phil suggested on IRC a LOCAL_VARS option that has the effect of making
> all newly-declared variables local; e.g.,
>
> % unset x y
> % () { setopt localvars; x=42; typeset -g y=43 }
> % echo $+x $+y
> 0 1
> %
>
> I'm attaching a proof of concept patch (work in progress; see top of the
> attachment for known issues), but WDYT of the the general concept?

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.

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.

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.

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.

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.