On 18.06.2018 at 00:09, Enno Woortmann wrote:
> In my opinion that's the argument to return null for either parameters
> which aren't an array or empty arrays simply because a first/last key
> isn't present and null is the value to be returned for an undefined state.
> I've tested this behavior with other array_* functions which are
> provided in the PHP core and they provide null consistently, eg.:
>
> root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r "var_dump(array_keys(1));"
> PHP Warning: array_keys() expects parameter 1 to be array, integer
> given in Command line code on line 1
> NULL
> root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r
> "var_dump(array_values('hello'));"
> PHP Warning: array_values() expects parameter 1 to be array, string
> given in Command line code on line 1
> NULL
> root@WOL-Soft-DEVVM:/var/www/WOL-Soft# php -r "var_dump(array_flip(null));"
> PHP Warning: array_flip() expects parameter 1 to be array, null given
> in Command line code on line 1
> NULL
These return values are due to zend_parse_parameters() failures (i.e.
the given types don't match the expected types), and it's customary to
return NULL in this case (under strict typing an exception would be
thrown instead). However, most functions signal other failures by
returning FALSE, for instance:
var_dump(array_search('foo', [])); // => bool(false)
I would prefer, if these other functions would return NULL, though, but
we can't change that for BC reasons.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
