Re: Changing the way bash expands associative array subscripts

[Koichi Murase]

.2021年4月9日(金) 23:53 Chet Ramey <chet.ramey@case.edu>:
> On 4/8/21 6:23 PM, Koichi Murase wrote:
> > I currently don't have any better idea, but in that way, it seems to
> > me that there is no way to represent a reference to an element
> > associated with key=@ under the new `assoc_expand_once', which was
> > what I wanted to argue in my previous reply.
>
> Under what circumstances?

We were talking about indirect expansions and name references in that
branch of the reply tree.  As I have quoted in my previous reply:

> > > That said, the fact that you can put 'a[@]' in an indirect variable and
> > > get an array expansion out of "${!x}" is completely repulsive to me.

Currently, we need to write as «iref='a[$key]'; echo "${!iref}"» so
that $key is not expanded until the referencing (just like «unset
'a[$key]'»). If the new assoc_expand_once enables the indirect
expansions of the form «iref="d[$key]"; echo "${!iref}"» like «unset
"a[$key]"» and also if we don't change the current behavior of
«iref=a[@]; echo "${!iref}"» (being expanded to all the elements of
the array) as Greg's suggestion, we need to work around the case key=@
for «iref="d[$key]"; echo "${!iref}"». However, it seems to me that
there is no workaround. What string should we assign to `iref' to
create a reference to the element associated with key=@ with Greg's
suggestion?

The same discussion applies to the name references «declare -n
nref="a[$key]"; echo "$nref"». If «declare -n nref=a[@]; echo "$nref"»
continues to expand to all the elements while supporting «declare -n
nref="a[$key]"», how can we create a name reference to the element
associated with key=@?

a. Maybe, one solution is that we don't change the current behavior of
expanding array subscripts in indirect expansions ${!iref} and
namerefs «declare -n». But in this case, users still need to properly
quote the array subscripts as «iref='a[$key]'» or «declare -n
nref='a[$key]'». But it would introduce a new inconsistency against
the proposed «unset "a[$key]"» in the new assoc_expand_once.

b. Another option is to stop treating a[@] and a[*] specially also in
indirect expansions and name references, which may break existing
codes.

c. Or we cannot create a reference to the element associated with
key=@ or key=* in the new `assoc_expand_once' mode. We need to go back
to the compat mode to use references to elements of arbitrary keys.

--
Koichi