bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changing the way bash expands associative array subscripts


From: Koichi Murase
Subject: Re: Changing the way bash expands associative array subscripts
Date: Mon, 19 Apr 2021 14:09:08 +0900

2021年4月19日(月) 6:46 Chet Ramey <chet.ramey@case.edu>:
> On 4/13/21 5:18 AM, Koichi Murase wrote:
> > I actually doubt whether there are real use cases for the behavior
> > that «iref=a[@]; ${!iref}» or «declare -n nref=a[@]; $nref» expands to
> > all the elements of *associative* arrays.  Maybe it is useful to
> > expand the indexed arrays in this way because indexed arrays contain a
> > sequence of values.  But associative arrays usually contain a set of
> > unordered key-value pairs, so I guess there are not so many chances to
> > expand only the values without specifying keys.
>
> I'd dispute that. There are multiple use cases for the set of values in an
> associative array.

OK.

> > It's just a naive idea and may be imperfect, but how about changing
> > the behavior of assoc[@] (except for "${assoc[@]}") only for
> > associative arrays while keeping the current behavior for indexed
> > arrays?
>
> Some of this is reasonable.

Thank you for your reply to each case.  Anyway, please feel free to
reject/accept each of them since this is my naive idea.

>   In the following list, the items marked with (*) are the
> > behavior different from the current one. I listed examples for key=@,
> > but the same for key=*.
> >
> >    unset 'indexed' # remove the indexed array
> >    unset 'assoc' # remove the associative array
> >    unset 'indexed[@]' # empty the array (*)
> >    unset 'assoc[@]' # remove the element of key=@ (*)
>
> We've already discussed these. I'm ok with the change to associative
> arrays, since there's already a way to do it and it seems more
> straightforward to remove the element with key `@'. I'd have to think about
> the changed to indexed arrays, since you can already do it with
> `indexed=()'. It's a novel new use case.
>
> >    iref=indexed[@]; ${!iref} # all the elements
> >    iref=assoc[@]; ${!iref} # the element of key=@ (*)
>
> No, there's no reason to have ${!iref} and ${assoc[@]} behave differently.
>
> >    declare -n nref=indexed[@] # reference all the elements
> >    declare -n nref=assoc[@] # reference the element of key=@ (*)
>
> Same reason.
>
> >    test -v 'indexed[@]'
> >    [ -v 'indexed[@]' ]
> >    [[ -v indexed[@] ]] # test if the indexed array is non-empty
> >    test -v 'assoc[@]'
> >    [ -v 'assoc[@]' ]
> >    [[ -v assoc[@] ]] # test if the associative array has the key '@' (*)
>
> I'm ok with this.
>
> >    printf -v 'indexed[@]' xxx # error
> >    printf -v 'assoc[@]' xxx # assign to the element of key=@ (*)
>
> I think this is ok, too, for the same reason as:
>
> > We don't change the following behavior of associative arrays where the
> > syntactic information may distinguish a[$key] from a[@]:
> >
> >    indexed[@]=xxx, assoc[@]=xxx # error
>
> I think it's ok to allow
>
> assoc[@]=value
>
> since
>
> indexed[@]=xxx is going to be an error no matter which behavior you choose
> because it's an invalid arithmetic expression.

--
Koichi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]