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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
