Source
algaecube•

This would be awesome. Lots of great RFC's going through lately, I'm excited for the future of PHP.

16
[deleted]•

[deleted]

1
zimzat•

I could see some good usages for this, but I don't understand why it couldn't support string keys the same way that array_merge does. The consistency with argument unpacking seems like a red herring. It'll lose a lot of potential usages if the developer has to know ahead of time whether the keys are strings or numerics.

11
ocramiusOPZF2 / Doctrine Team•

I'd say that this is a good limitation for now: semantics around unpacking of maps should likely be discussed in a separate RFC, if needed. The current proposal is a subset of possible unpacking operations, so it can be expanded.

3
zimzat•

I'm hesitant to agree. Technically you're correct that it could be expanded in the future, and if we were talking about a framework that might do it in 3-6 months I could see this as a plausible step in the right direction, but if it doesn't happen for 7.4 (which might be what you mean and I'm jumping the gun here) then the earliest we would see that happening is ~20 months from now in 7.5 or 8.1. It would also mean that a lot of frameworks will have to delay making use of it until their minimum version is above the version of PHP that throws type errors for strings (e.g. ~3-4 years).

For what it's worth JavaScript has unpacking for arguments, arrays, and objects so there's decent precedent on the semantics.

6
ocramiusOPZF2 / Doctrine Team•

Send a second RFC to expand this then: there's a few more months of time to land stuff into 7.4.

5
PHPRogerAllen•

JS and PHP are not comparable. array_merge is "magic", it's neither a concat nor a merge, it's both at the same time,therefore it's ambiguous

​

use + if you want to merge maps, ... if you want to concat sequences

1
tie_salter•

Having it just work on lists fits with the existing variadic expansion rules already in functions, having the same operator with different functionality depending on where it's used will just be confusing. Also, would it work like array_merge or array_replace?

1
zimzat•

having the same operator with different functionality depending on where it's used will just be confusing.

The + operator does different things based on whether it's used with arrays or numbers. The same context-sensitive nature broadly applies for many other symbols used in any language. For example: [/] for array update, array append, array access, or array create depending on the context it is used in, or (/) for function declarations, function calls, creating objects with parameters, or determining operator precedence.

Also, would it work like array_merge or array_replace?

array_merge, otherwise it would work the opposite of its usage in function calls rather than complimentary.

1
Wes666•

https://externals.io/message/103452#103453

​

there is no "concat" of string keys, only a union... unless you actually reorder the keys

2
zimzat•

Thank you for linking to the discussion thread.

The comment by Nikita is exactly my argument as well.

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).

Whether I have a numeric array or a string array, I don't want to have to think about that when my intent is to merge them together. Trying to figure out which is which and when to apply which is just another complexity I don't need.

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.

I'd really like to know why that limitation is being applied. I don't see any supplied justification for that view.

["a" => 1, "b" => 2, ...["a" => 3]]

or is it equal to ["a" => 3, "b" => 2] overlaps the functionality of the + operator (bad idea imo)

It doesn't actually, because + ignores the values in the right half if it already exists (even if they're numeric, which makes it occasionally hazardous to use in a generic Collection object) (whereas array_merge is the opposite). The result would instead be ["a" => 1, "b" => 2] with +

1
brendt_gd•

I disagree. Spreading arrays only makes sense if you're working with a list of items.

If you want to spread maps, you're dealing with lots of implicit context and cognitive overhead. In my experience, these cases are better handled with objects instead of arrays.

1
zimzat•

An object only works when you know exactly what keys something will have ahead of time. There are still many times where you'll be working with an arbitrary set of data that needs to be keyed off a string and then transformed in some way.

In checking my most recent project's code base for usages of array_merge I've found plenty of scenarios where it's a list, a few where it could be either (generic Collection object), but one specific one is a map. It's a map of fields (the keys) to their type (the values), ordered by occurrence, and it's merging the map of previously known values on top of that to preserve the previously known. That's a bit of generic array logic that couldn't be duplicated with an object.

I also use + a lot, but that's mainly because I find it much more succinct than array_merge() and know ahead of time that the array keys shouldn't, theoretically, be conflicting.

JS has an object spread operator that works much the way I'm talking about having it work for arrays in PHP. It gets used very frequently to do much the same thing as above.

1
MaxGhost•

After seeing all the fun stuff you can do with array spreads with React/Redux, I'd be so excited to get this. It would make a lot of simple array operations so much simpler to write!

8
phpdevster•

Yep. This would be a great addition to PHP's already unparalleled array functions library.

1
lawpoop•

Can you post some examples?

1
MaxGhost•

Specifically related to Redux, https://redux.js.org/recipes/using-object-spread-operator

Some of these examples won't work as-is because currently the PHP impl doesn't support string keys (see RFC for the reasons).

But basically, things like prefixing an element into a new array becomes something like $newArr = [$newItem, ...$oldArr];, as described in the RFC.

2
Code_otter•

I could have used this just last week.

1
parks_canada•

I'm excited about the possibility of this and array comprehensions like Python has.

1
pmallinj•

Argument unpacking is cool to type check non associative arrays but I hope someday it gets replaced by array type checks. Something like function (array[string] $x) {} it would allow to improve code a lot.

1
2012-09-04•

Just wait until you have to review crap code using this in the next 10 years.

-3†
pmallinj•

I can't see why crap code using array merge can get crappier with this.

2
secretvrdev•

See it the same. Why did i never ever missed that feature? Because its unreadable.

1