\On Tue, Feb 16, 2016 at 1:30 AM, Linda Walsh <b...@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.