Re: [RFC] Additional splat operator usage

On 04/11/2014 20:55, Andrea Faulds wrote:

If anything, I think I would expect the keys of splatted arrays to be discarded, since it seems most natural to use this in a list context, but I can imagine always having to check in the manual.

I don’t think they’d be discarded. The named parameters RFC proposes that named keys be kept by ..., and I’d prefer we do that since it makes more sense anyway:

Interestingly, the current behaviour of PHP is to issue an error in this situtation ("Catchable fatal error: Cannot unpack array with string keys"), while HHVM simply strips off the keys and unpacks the values: http://3v4l.org/vi7fn However, if you present multiple arrays with integer keys, HHVM issues an error ("Fatal error: Only the last parameter in a function call is allowed to use ..."), while PHP happily merges them, appending and renumbering the keys as though array_merge() had been used: http://3v4l.org/fXE8U

[‘foo’=>’bar] and [...[’foo’=>’bar’]] should act the same, no?

By that logic, [42 => true] and [...[42 => true]] should also act the same, but if we make it a short-hand for array_merge(), then numeric keys will be discarded. In fact, I think that's what concerns me about this proposal - it's *not* obvious how it should behave, and different use cases lend themselves to different answers. -- Rowan Collins [IMSoP]