Re: Up-scope named references, vs. ksh

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 3/5/24, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Mon, Mar 4, 2024 at 5:05 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>>
>> Isn't defaulting to a scalar type fairly normal.
>
> Sure, but Stephane wants a global that's a blank slate for anything to
> be assigned to.  I don't think we have a way to do that -- the way the
> implementation works in the absence of namerefs is to actually
> remove/free the parameter and create a new one.  If there are locals
> pointing to the global via pm->old, and the global gets removed, all
> the locals are also destroyed.
>
>> A different problem I'm finding is with not being able to hide the
>> reference type of a variable in a called function:
>
> That's actually "correct" -- from the doc:
>
>  When a _named reference_ is created with 'typeset -n', all uses of PNAME
>  in assignments and expansions instead assign to or expand RNAME.  This
>  also applies to 'unset PNAME' and to most subsequent uses of 'typeset'
>  with the exception of 'typeset -n' and 'typeset +n'
>
> I admit this is a little weird when the named reference is inherited
> from another scope.  The most recent FAQ entry that I patched actually
> suggests using "private -n var" to prevent downward scope leakage of
> namerefs.

Is this possible to change? I feel like if "typeset myvar" (or "local
myvar") cannot be depended on to create a local parameter, a lot of
code will no longer be safe that previously was (in the sense that it
doesn't break if calling code / the shell environmnet has certain
parameters defined). Surely we cannot expect everyone to add +n to
every single "local" statement? If the current behavior is wanted, one
can always use typeset -g to get it, presumably? And that would be
more backward compatible, right?

Like say I have typeset -n foo=PS1 in my .zshrc because I don't like
writing $PS1 manually, now any code I call which has a "local foo" is
broken, which is not great. They have explicitly added their "local
foo" to be able to use the name 'foo' regardless of the calling
environment... "private -n foo" works in this case too, but I still
hold my opinion.

-- 
Mikael Magnusson