++= appendAssign operator (#7346)

[raccmonteiro]

Description

Closes #7346

Tests + Formatting

> mut a = [1 2 3]
> $a ++= [4 5 6]
> $a
[1 2 3 4 5 6]

[webbedspace]

Please write tests. Just copy-paste the ++ tests and tweak them if you must.

[rgwood]

Thanks for the PR! Agreed with @webbedspace that this needs some tests.

[raccmonteiro]

Added some tests.
But, I noticed this does not work

> mut a = [1 2 3]
> $a ++= [a]

results in this error:

This should be a valid case, right? I did not understood yet where this error is being thrown.
If someone wants to help please be free to make the changes :)

[sholderbach]

Your code and tests look good to me!

[sholderbach]

I think constraining the type of a mutable variable to the one at assignment time sounds less surprising, but the question is if for this the list should be opaque with the inner type erased (list<any>).

Added some tests. But, I noticed this does not work

> mut a = [1 2 3]
> $a ++= [a]

results in this error:

This should be a valid case, right? I did not understood yet where this error is being thrown. If someone wants to help please be free to make the changes :)

[rgwood]

I think constraining the type of a mutable variable to the one at assignment time sounds less surprising

I agree, this seems like the right behaviour to me.

the question is if for this the list should be opaque with the inner type erased (list).

I think a should be as specific as possible by default (list<int>), but we should allow the user to opt into list<any>. Beyond the scope of this PR but it would be nice to be able to do something like mut a: list<any> = [1 2 3]

[rgwood]

I think this could use another test checking that the case above (mut a = [1 2 3]; $a ++= [a]) returns an error. But it's not 100% necessary and this could be merged as is. Thanks @raccmonteiro!

[rgwood]

btw, this is interesting (but not caused by this PR, no need to fix it here):

I haven't taken a look at the implementation but it looks like we are not handling covariance correctly.

[raccmonteiro]

I think this could use another test checking that the case above (mut a = [1 2 3]; $a ++= [a]) returns an error. But it's not 100% necessary and this could be merged as is. Thanks @raccmonteiro!

I added this case, I didn't do it before because I thought this should not result in error.

Thank you both for explaining your thoughts

[rgwood]

Thanks for another great PR!