I was not polite either. My IRL bad mood leaked onto the internet.

I believe not unpacking keys with function arguments was because of the potential - no, guaranteed - confusion with associative arrays. Without a named arguments feature, PHP can only really do one thing: unpack the array in the order the entries were inserted. The order you'd get with a foreach. That runs directly contrary to how associative arrays (aka hashes or dictionaries) are typically used in programming: where the order doesn't matter in the slightest. Unpacking an associative array into function arguments just does not make sense right now.

But that doesn't apply to unpacking arrays *into arrays*. However, what could be a problem is the potential for one unpacked array to overwrite the keys of a previous unpacked array.

Regardless of all of the above, this sort of change needs some discussion in a place that's better suited than this bug tracker, ie. the mailing list. Possibly an RFC, depending how it goes.

@requinx, you'd be entirely justified in it (maybe not to the extent of an eye for an eye), but I did basically come in and shit all over work volunteered by good people.

I'll bring one of my comments (redacted the bad parts) from the old issue thread, as it is still pertinent.

I agree discussion would be necessary to map out all advantages and disadvantages - I wouldn't know where to start submitting an RFC. I don't know C++, so I could not contribute to PHP in that way anyway. Though I strongly feel this would be a very useful feature.


--- from previous issue ---

Are there any downsides to allowing string keys when unpacking inside arrays?

I agree that allowing string keys for function arguments doesn't seem to semantically quite fit together. Indexes don't map to arbitrary strings.

But why not for spreading within an array?

You could then simultaneously define default values, user customisable values and fixed values all within the array syntax.

For example:

$custom = [
  'value' => true,
];

$values = [
  'value' => false,
  ...$custom
  'fixed-value' => $whatever
];

Indexed arrays would concatenate, like with array_merge.

String keys will overwrite, like with array_merge.

I feel it makes more sense for the semantics to match array_merge.

--- end comment ---


> "However, what could be a problem is the potential for one unpacked array to overwrite the keys of a previous unpacked array."

I think that would be the point of unpacking inside the array.

I think people tend to conceptualise associative arrays as being different from indexed arrays. They are used for different purposes. So, I think it makes sense that their behaviour would differ when used in certain conditions.

PHP already treats arrays differently in certain cases, like when passed to array_merge. The RFC even proposes the array unpacking inside arrays as a replacement for array_merge when simply concatenating index arrays.

Nobody really explicitly defines indexes in an array, they leave that to the interpreter, unless they're using generated code or something, but PHP doesn't seem to care if you explicitly define indexes, so long as they increment from zero.

I think people use associative arrays in PHP like objects are used in JavaScript, for the most part. The order of properties was never guaranteed when iterating them in JS. But that didn't really cause all that many problems, though order of properties is now guaranteed in newer interpreters to be in the order in which they were assigned.

But, one order which will always be guaranteed, is the order in which string keys are defined, due to the code itself being linear. So, order underlying isn't an issue, even though PHP does indeed maintain order during iteration.

PHP/JS is one of the most common pairings. By necessity, given, but, nonetheless paired via the web.

I feel it makes sense for string keys to overwrite. It's what you'd intuitively expect to happen in the above example.

It has a lot of uses. I can't help but find this just icky:

$custom = [
  'value' => true
];

$values = array_merge([
  'value' => false
], $custom, [
  'fixed-value' => $whatever
]);


I was actually in converting an example like the above to the new unpacking syntax that I discovered string keys are currently not allowed.

I never knew PHP supported this - this kind of renders any real necessity outside of "might as well do it anyway" quite moot.

$a1 = [
    'one' => 'foo'
];

$a2 = [
    'one' => 'bar',
    'two' => 2
];

$a3 = $a1 + $a2;

var_dump($a3);

// Yields:
//
// array(2) {
//    ["one"]=>
//    string(3) "foo"
//    ["two"]=>
//    int(2)
// }

Saying that, it's not as neat when used for the purpose I describe in an earlier comment.

No, wait, I'm being a massive tool.

It doesn't overwrite string keys, it will only add attributes which don't already exist in the left operand.

If you haven't already, it's worth looking through the discussion of the original RFC, where string key unpacking was originally included, but dropped to get the core feature in: https://externals.io/message/103452 https://externals.io/message/105072 https://externals.io/message/103458

I believe the main reason it was dropped was not because there wasn't support for the concept in general, but because it wasn't clear exactly how it should behave. As you've discovered, we already have array_merge and the + operator with different behaviour; it's unclear if the ... operator should mimic one of those, or be yet a third variation of the same thing.

As requinix touched on, it was also deemed important for unpacking within arrays to match unpacking in argument lists. If named arguments are added in future, then we might have a stronger reason for picking a particular behaviour for this scenario; conversely, if we pick a behaviour now, we might regret it when adding named arguments.

@rowan,

Those are some excellent points. I understand the reasoning for the omission.

Thank you. I shall eagerly await named arguments - that sounds like a useful feature,