[WIP][RFC]Spread Operator in Array

[jhdxr]

this is the implement for RFC Spread Operator in Array Expression

both the RFC and this PR are still WIP, but since most of the implement has been done, I'd like to create PR first. it's no harm to give people more time to review this, isn't it?

todo list:

• finish RFC
• test cases
• opcache
• deal with list(), since it also use array_pair

[nikic]

Thanks for working on this! From a quick look the patch looks reasonable.

One somewhat contentious issue that came up the last time we discussed this in room 11 is the behavior of string keys. This PR implements the same semantics as array_merge. An alternative would be to always discard keys and append elements. Another would be to error on string keys (that's what argument unpacking does). I think it would be good to discuss this question in the RFC and provide a rationale why the behavior was chosen.

[azjezz]

great work, i was going to propose something similar to this before but never get to it.
you may take a look at this gist : https://gist.github.com/azjezz/e174bb34a23d298fea4b9b25ff0ca8ca

[Llbe]

A question: will this be supported?

class C
  {
    public const FOO = [1, 2, 3];

    public const BAR = [... self::FOO, 4, 5];
  }

[jhdxr]

hi @Llbe , this is supposed to be supported since it's a constant expression. Unfortunately I got a core dump when I try to run your example. I'll look into it later. thanks.

---

update: I cannot reproduce the crash on my windows. I'll finish updating the implement first then go back to the core dump.

[Llbe]

@jhdxr: another question (sorry I'm not on internals yet), the RFC doesn't mention how empty arrays are handled.

I assume that $foo = []; $bar = [... $foo]; will lead to $bar === []. Like array_push() since 7.3.

[jhdxr]

I assume that $foo = []; $bar = [... $foo]; will lead to $bar === [].

Yes, you are right.

[nikic]

Some changes in opcache are likely going to be needed. A good starting point is to look for ADD_ARRAY_ELEMENT uses in ext/opcache and see if the new UNPACK opcode needs similar treatment.

[datashaman]

Question: will this support destructuring assignment as well?

$arr = ['a', 'b', 'c', 'd'];
[$head, ...$tail] = $arr;
// $head == 'a';
// $tail == ['b', 'c', 'd'];

That's pretty neat for Haskell-style list splitting like x:xs.

[jhdxr]

@datashaman no, spread operator with list is not included in the RFC. I do have a plan for it but there is some questions I have to clear before proposing another RFC.

[nikic]

Do you need help with opcache support?

[nikic]

zend_opcode.c also needs updates (add ADD_ARRAY_UNPACK next to ADD_ARRAY_ELEMENT).

[jhdxr]

@nikic Yes, it will be very helpful. thank you.

I have another branch used for developing and testing with opcache, but the progress is very slow. maybe you can just ignore this one (:з」∠)

[nikic]

Opcache support is done, and I've also added a few more bits of test coverage.

[jhdxr]

thank you @nikic

[isaiddestroy]

Maybe it makes sense to use a different syntax instead of ..., but add support of arrays with string keys? It will be very helpful in many cases.