Re: RFE: Fix the name collision issues and typing issues with namerefs, improve various issues for function libraries

[George]

On Sat, 2017-06-17 at 20:23 -0400, Chet Ramey wrote:
> On 6/14/17 12:04 PM, tetsujin@scope-eye.net wrote:
> > 
> > 
> > This is relevant to my interests!
> > 
> > So first off, the circular reference problem with "declare -n"
> > apparently doesn't exist in Korn Shell: If you "typeset -n x=$1", and
> > $1 is "x", it's not a circular reference. The nameref seems to take
> > the origin of the name into account when creating the nameref: If $1
> > is used to provide the name for a nameref within a function, then the
> > nameref refers to a variable in the scope of the function's caller.
> > But if the name for the nameref is taken from another parameter, or a
> > string literal, then the variable is drawn from the scope of the
> > function itself. It seems a little "black magic" in a way but it has
> > the benefit of neatly matching some important common use-cases. I
> > think Bash should either adopt something similar, or provide another
> > mechanism to exclude function-local variables from nameref
> > construction.
> I've gotten a suggestion that function-scope circular references should
> always be resolved beginning at the previous scope, but I haven't done
> anything to implement that yet.
> 
> There are a couple of problems that make it less clean to implement the
> Korn shell mechanism. First, declare is a shell builtin, which means that
> its arguments are expanded before it sees them. x=$1 and x=x both look
> the same to declare when it sees them. The second is dynamic scoping,
> which makes resolution tricker. The korn shell uses static scoping, so it
> only has to look at the current scope and the global scope (which makes
> the x=$1 case even more irregular).
> 
The functionality is the important thing here, not the specific semantics. 
Personally I wouldn't want to emulate the semantics ksh uses to trigger
this behavior anyway. It's the sort of thing that kind of makes sense in some 
ways (i.e. the variable name comes from the caller...  So the variable
ultimately identified in the nameref also comes from the caller) but the 
inconsistency there, of "typeset -n" behaving differently depending on where
the name comes from, is very unappealing to me. I'd much rather see this 
behavior activated by an explicit argument to declare, like this:
declare --caller-scope-nameref result_var=$whatever
Or this:
declare -n --scope=caller result_var=$whatever
I think switching the behavior in a clear-cut way like that is much preferable 
anyway. The fact that it's also easier to implement than the "black
magic" is like a bonus.
This also shouldn't be triggered by circular references: I think it's just more 
"black magic" and it's still an incomplete solution to the problem:
- Caller has locally-declared $x and $y, calls "f x" to modify its $x
- Function "f" internally creates a nameref "declare -n caller_var=$1" but it 
also has $x as a local variable, so $caller_var refers to that one.
(It's not a circular reference, but it's not the right variable either.)
My understanding of Bash's variable scoping implementation is a bit limited at 
the moment, I think there are still some gaps in my understanding of
it, but I'm pretty sure the approach I described would still work.