Closed aidantwoods closed 6 years ago
I could only find one instance where this seemed to be an appropriate change, there may be more I've missed though.
In particular I could only find the given instance where ordering mattered (other uses of @param array<int, string>
appeared to be behaving more like sets so a change like this isn't so beneficial given psalm
is being run in unit tests to cover the type angle – though runtime checking probably can't hurt if desired).
Swap an instance of
@param array<int, string> $pieces
for@param string ...$pieces
. This lets PHP do some type checking at runtime for ordered collections.This also serves to explicitly state that any intended ordering must be based on the array's internal ordering (and not on, say, the numerical order of the array keys – which may differ if they were manually set out of order for example).
I could only find one instance where this seemed to be an appropriate change, there may be more I've missed though.
It is possible to be preferable to reject this change in favour of maybe being able to keep the API the same when proper generics hopefully land in PHP. Though as mentioned, there is a subtly that variadics address, which is making it explicit where the ordering of a collection is obtained from – a proper generic PHP
array<int, string>
would likely suffer from the numerical key order and array internal order being able to disagree (as normal PHParray
does today). Furthermore, when PHP has proper generics it will be possible to implement type-safe ordered lists, soarray<int, string>
will probably no longer be the best choice anyway 🤷♂️