Reinstating old behaviour of += with lists

[Ghoulboy78]

Properly fixes #1152, as opposed to the hack-fix in #1154 which just works around it.
In ye olden days, when the += operator simply called Value.add(), this is the behaviour that would occur, i.e.: doing l=[]; l+=['3','4'], would result in l==['3','4'], whereas now it results in l==[['3','4']] . This broke shapes.scl accidentally. I have also fixed this behaviour for maps, cos it's also broken there.

[17183248569]

Oh no. 🤦‍
Do you think the semantics of += are not ambiguous enough?

[Firigion]

I think that if you want to use += on lists to mean lhs = lhs + rhs, you need to also add an easy way to append into a list. += was added as append because put(my_list, null, element) is way to verbose for such a common action. I think += functioning as append is a fantastic addition and old code that used the fact that adding lists of the same length wolud add them element-wise just need to switch their l += [1,2] to l = l+[1,2], which is not that bad.

Also, l=[]; l+=['3','4'] returning l==['3','4'] doesn't make much sense. If addition between lists is meant to add element-wise, then this should error out. If it's meant to extend a list (append all the contents of the right hand side list into the end of the left hand side one), this is gonna silently fail to work as expected when the two lists are the same length. That is, unless you also remove the ability to add element-wise, which I strongly recommend against, since we don't have an alternative datatype to handle element-wise operations between arrays.

Basically, this bolis down to what is more commonly used: extend or append. One should keep the += action and the other one stick to put(list, null, value, mode). My vote is for append to keep it.

[Ghoulboy78]

Ok, well what I did was make it so if you do l += a_list_or_map, the elements of a_list_or_map (for a map it's the key-value pairs in a list, like you used to declare them in the olden days) get added one by one to the end of list l. For anything else though, doing l+=v extends the list and sticks v to the end of l. But you can still do element-wise addition with l = l+a_list (not with a map I don't think). Basically I didn't touch + operator, just += for lists, which is called via the append() method in AbstractListValue class.

[Firigion]

So += appends except when the right hand side is a an iterable of any size, in which case it extends (or concatenates)? If that's the case, I recommend an extensive explanation in the docs, both in put and in += sections. I don't like it personally, but let's see what other people think.

[Ghoulboy78]

But you see Firi, I'm reinstating old behaviour which was accidentally removed earlier on, and no one noticed that it broke stuff.

[Firigion]

I know, but I don't like it, and I assume gnemon changed it on purpose :P

Still, if you are making a PR reisntating the old behaviour, you can use the opportunity to clarify the thing to new user with a good documentation, because the behaviour is anything but trivial.

[Ghoulboy78]

I made a discord thread to discuss it: https://discord.com/channels/882822986795716608/882831843165085758/921494453682864129

[gnembon]

Yeah - current behaviour is less confusing then proposed. 'put' has clear usecases for 'insert' and 'extend'. Plus that would break a few examples that are currently in the docs and work because += assume the value to add is always a scalar.