>
>
> * Are integer keys preserved? I'm assuming no, as otherwise it would
> be the same as `$a + $b`.
>
> $arr[...] = $arr;
> should be the same as
> foreach ($arr as $v) { $arr[] = $v; }
>
> all other answers should be answered from this and consistency
Since `$arr1[...] = $arr2;` should be consistent with `foreach ($arr2 as
$v) { $arr1[] = $v; }` (or more succinctly with a bodiless loop: `foreach
($arr2 as $arr1[]);`. In this regard, it appears to destroy $arr2 keys
while appending. So for cases with non-numeric keys that choke the spread
operator within `array_push()`, then the bodiless loop isn't horrific.
What I do find unsettling is that the spread operator in its current
implementations always serves to unpack the payload that follows it (on its
right side). However, in this new implementation, the three dots are
entombed in square braces -- it would be inconsistent with the language.
I think it would be more intuitive to implement an array "appending"
functionality with "concatenating" syntax. The `.=` syntax already exists,
but is forbidden from use on non-strings. If you want to implement this
preexisting syntax as an array concatenation operator, then it is a blank
slate -- you can decree whatever behaviors you wish for it without blurring
what the combined operator does with strings. This opportunity is similar
to how `+=` acts as an addition-assignment operator or an array union
operator depending on context.
I don't think I have an appetite for going down this road, but if so, I
could imagine appending with `$all = $arr1 . $arr2 . $arr3;` The reason
that I find this unsavory is probably because it becomes harder to intuit a
data type by merely scanning code functionality. If the variable names
aren't indicative and there is no type hinting, it will be hard to discern
string variables from array variables without more context.
I suppose my parting thought on this discussion is that the spread operator
is just not the best tool for this job -- if this is a job worth doing at
all.
Mick
