Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)

[Dan Douglas]

\On Tue, Feb 16, 2016 at 1:30 AM, Linda Walsh <bash@tlinx.org> wrote:
>
>
> Dan Douglas wrote:
>>
>> Ah so `arr+=([a]=x [b]=y)` will no longer be the same as `arr+=([a]+=x
>> [b]+=y)`? I never liked that for associative arrays because the only
>> workaround was to do multiple arr[key]= assignments to update or add
>> more than one element at a time.
>>
>> My thinking was that this is due to bash's unique auto-incrementing of
>> indexed array keys. Since in ksh you're not allowed to specify an
>> index for one element of a compound assignment without specifying it
>> for all elements, bash has some additional things to consider.
>>
>>  ~ $ bash-4.2 -c 'typeset -ia a=({0..5}); a+=([0]+=1 {2..4}); typeset -p
>> a'
>> declare -ai a='([0]="1" [1]="3" [2]="5" [3]="7" [4]="4" [5]="5")'
>>
>> Bash 4.4:
>>  ~ $ ./doc/programs/bash-build/bash -c 'typeset -ia a=({0..5});
>> a+=([0]+=1 {2..4}); typeset -p a'
>> declare -ai a=([0]="1" [1]="2" [2]="3" [3]="4" [4]="4" [5]="5")
>>
>> I almost think it makes sense to treat ordered and unordered
>> collections differently.
>
> Why?
>>
>>  With an unordered collection an outer +=
>> should obviously mean "add or update for each assignment".
>
> For an array, you mean? like
> array a=( 1 2 3)
> array a+=( 4 5 6)
> then you get array a=(5 7 9). Or are you saying
> for an ordered array you'd have to use indexes, like
> array a=(1 2 3)
> array a+=([0]=4 [1]=7 [2]=10), then that would do your
> -- but wouldn't that be doing a vector operation of
> sorts?

I mean exactly the example I posted. In bash if you explicitly specify
an index for an assignment at any point within an auto-incrementing
compound assignment, bash will jump to that position and continue
incrementing. Bash is the only shell that has that property.

There's nothing wrong with that feature but the question of what to do
when an auto-incrementing assignment encounters an element with a
previous value isn't as obvious because the semantics differ. For an
ordered collection the outer += translates to "append to the list"
while with an unordered collection it roughly means to "union" the two
sets of keys.

You could argue that for consistency bash should always bulldoze over
previous values even if auto-incrementing keys. That makes sense from
a certain perspective and is consistent. From another perspective you
might expect the outer += to mean append for each sub-assignment to an
auto-incrementing array when not appending to the end of the array.
That especially makes sense if it's an integer array. I can understand
the logic either way.

I wrote about all of these issues years ago (I'm pretty sure also on
this list) so people probably know about them and possibly believed
the old behavior was by design like I did.

http://wiki.bash-hackers.org/syntax/arrays#bugs_and_portability_considerations.