Hi internals,
I'd like to start the discussion for RFC: Spread Operator in Array Expression. In short, this is a syntax similar to argument unpacking, but for array.
You can find the implementation here. It's still WIP, but I'll finish it in the next following weeks.
Thanks & Best regards,
CHU Zhaowei
Hi, I worked together with Chris Wright, author of the other RFC covering
the same thing.
You will find there is very little agreement on how this should work, which
is the reason the RFC stalled... not because we didn't try.
The most important thing is that we don't want it work like array_merge();
in other words, it must not cover both lists and maps at the same time.
What you are proposing overlaps the $arr1 + $arr2 operator functionality.
Everything boils down to this:
["a" => 1, "b" => 2, ...["a" => 3]]
is this equal to
["b" => 2, "a" => 3]
imo reasonable... "ordered map concat". ie not only it overwrites the
value, but it also re-positions the key
or is it equal to
["a" => 3, "b" => 2]
overlaps the functionality of the + operator (bad idea imo)
or is it equal to
["a" => 1, "b" => 2, 0 => 3]
ie discards the key, works like array_push()
?
Also my opinion: it should work like push(). If people really want the
"ordered map concat" functionality, then it should be an entirely different
operator.
Good luck
Hi, I worked together with Chris Wright, author of the other RFC covering
the same thing.
For reference: https://wiki.php.net/rfc/additional-splat-usage.
--
Christoph M. Becker
I didn't link it because that page was never updated with the progress we
made :P
Hi internals,
I'd like to start the discussion for RFC: Spread Operator in Array
Expression. In
short, this is a syntax similar to argument unpacking, but for array.You can find the implementation here. It's still WIP, but I'll
finish it in the next following weeks.
This looks reasonable to me. The array_merge() behavior is certainly the
one I would (in PHP) expect intuitively, and it is likely the most useful
one as well, striking a balance between behavior useful for pure vectors
and pure dictionaries (and falling short if it's not either ... as is usual
in PHP).
Nikita
Hi internals,
I'd like to start the discussion for RFC: Spread Operator in Array
Expression. In
short, this is a syntax similar to argument unpacking, but for array.You can find the implementation here. It's still WIP, but I'll
finish it in the next following weeks.This looks reasonable to me. The
array_merge()behavior is certainly the
one I would (in PHP) expect intuitively, and it is likely the most useful
one as well, striking a balance between behavior useful for pure vectors
and pure dictionaries (and falling short if it's not either ... as is usual
in PHP).Nikita
I think we have + and array_merge already. What we don't have is
something that concatenates solely with values and ignores keys, at
least not in a single step. I think ... can be that operator,
precisely because this is what it does for function calls as well.
In other words, this results in a completely sequentially ordered
array, regardless of the key structure of $rest, and does not
overwrite positions 0 and 1:
$data = [$first, $second, ...$rest];
Those are the semantics that I would like. I think + and
array_merge serve the other cases, so no need to deviate from how
this works with function calls, which are obviously positional and
will not overwrite previous values.
Le mercredi 21 novembre 2018, 22:46:42 CET Levi Morrison a écrit :
I think we have
+andarray_mergealready. What we don't have is
something that concatenates solely with values and ignores keys, at
least not in a single step. I think...can be that operator,
precisely because this is what it does for function calls as well.
For function calls you cannot use it with non-integer keys, the behavior is yet to be defined.
So if later there are named arguments and ... behaves like array_merge on parameters it would be weird to have it behave an other way on arrays.
I would make the ... operator behave the same in all places, so in array it should refuse string key as it does for function calls, for the time being.
Côme