Req #79288 [Com]: Allow string key array unpacking inside arrays with array_merge semantics

Edit report at https://bugs.php.net/bug.php?id=79288&edit=1 ID: 79288 Comment by: caelan89 at gmail dot com Reported by: caelan89 at gmail dot com Summary: Allow string key array unpacking inside arrays with array_merge semantics Status: Suspended Type: Feature/Change Request Package: Arrays related Operating System: n/a PHP Version: 7.4.2 Block user comment: N Private report: N New Comment: @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. Previous Comments: ------------------------------------------------------------------------ [2020-02-19 23:02:14] requinix@php.net 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. ------------------------------------------------------------------------ [2020-02-19 21:48:22] caelan89 at gmail dot com Description: ------------ A wise person by the handle of "nikic" once said to me: "Pro tip: Don't be a total dick in your bug reports, and you might get a more information reply next time." He is totally right. Don't be me. Don't go barging in with such an arrogant and demeaning tone. It does a disservice to all parties involved. See: https://bugs.php.net/bug.php?id=79285&edit=2 Please, if you would accept my apology, I am eager to discuss this feature: --- You've added array unpacking inside of arrays. However, I feel that it could benefit from an additional feature. You do not allow this: $a1 = [ 'test' => 1 ]; $a2 = [ 'test-2' => 2 ]; $a3 = [ ...$a1, ...$a2 ]; From my understanding, it would be semantically equivalent to: $a3 = array_merge($a1, $a2); Test script: --------------- $a1 = [ 'test' => 1 ]; $a2 = [ 'test-2' => 2 ]; $a3 = [ ...$a1, ...$a2 ]; ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=79288&edit=1