Re: LOCAL_VARS option ?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Thu, 19 Jan 2017, Peter Stephenson wrote:

> On Thu, 19 Jan 2017 07:47:53 -0800
> Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > 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

That's what zsh/param/private is for ...

> > 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.)

Perhaps rather than a setopt, this could be a property of functions --
something like "typeset -fT" so limited to the single function to which
it is applied.  That could be appropriate either for a generic "used
but not declared local" warning or the "implicit local var" feature,
though I would still have reservations about the latter.

Anyway the point is that we should make it easier to debug these issues
rather than make it easier to sweep them under the proverbial rug.