Re: LOCAL_VARS option ?

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Peter Stephenson wrote on Wed, Jan 25, 2017 at 09:24:38 +0000:
> On Wed, 25 Jan 2017 05:50:09 +0000
> Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > This case seems to be a false positive:
> > 
> > % () { typeset -A a; : ${a[hello world]::=foo} } 
> > (anon): scalar parameter hello world set in enclosing scope in function (anon)
> 
> There's a bogus parameter created for assistance in this case.  I didn't
> see what was going on so I didn't turn off the new warning.

Thanks for the fix.

> By the way, you won't get a warning in a case like this:
> 
> () {
>   local var=(one two)
>   () { var[3]=three; }
>   print $var
> }
> 
> which is probably OK because setting an element of something already
> presupposes it exists.
>

It does warn if the inner function assigns «var[3]=(three)».  I suppose
it shouldn't, for the same reason as the above case?

That would also enable «var[1,-1]=(...)» as an idiom to intentionally
overwrite an array declared in a parent function, without using the
reserved word 'typeset -ga' syntax.  (which is useful for scripts that
need to be compatible with older zsh's)

> The WARN_CREATE_GLOBAL equivalent does operate here, so you're
> protected if it doesn't exist.  You also get a warning if you trash
> the whole array:
> 
> () {
>   local var=(one two)
>   () { var=(three); }
>   print $var
> }

Cheers,

Daniel

> However, you don't get a warning if you change the array to something
> else:
> 
> () {
>   local var=(one two)
>   () { var=three; }
>   print $var
> }
> 
> That's a crucial case for protecting against problems and needs looking
> at in the tortuous type conversion logic.