Re: [RFC] Add is_list(mixed $value): bool to check for list-like arrays
| From: | Ben Ramsey | Date: | Mon, 21 Dec 2020 02:09:46 +0000 |
| Subject: | Re: [RFC] Add is_list(mixed $value): bool to check for list-like arrays | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112571@lists.php.net to get a copy of this message | ||
> On Dec 19, 2020, at 19:43, tyson andre <tysonandre775@hotmail.com>
> wrote:
>
> It can be useful to verify that the assumption that array keys are
> consecutive integers is correct, both for data that is being passed
> into a module or for validating data before returning it from a
> module. However, because it's currently inconvenient to do that, this
> has rarely been done in my experience.
I think there are some places where
Attachment: [application/pgp-signature] Message signed with OpenPGP signature.asc
is_list() could be unintuitive to
those who don’t understand some of the idiosyncrasies of PHP.
For example, with
$a = ['foo', 'bar', 'baz’];
is_list() will return true, but if you run $a through
asort(),
is_list() will return false because the keys are no longer
consecutive integers, but is there any doubt this is still a list?
Maybe in a pure sense, it’s not, but I think this could be confusing.
But now, if we do
$b = array_merge($a, ['qux', 'quux']);
$b is now back to being a list, so is_list($b) returns true.
While I understand the convenience is_list() provides--I myself have
implemented the opposite of this numerous times (e.g.,
is_dict())--it comes close to implying a data type that PHP doesn’t
have, and I think this could give a false sense of type-safety-ness
when using this function to check whether something is a 0-indexed
array.
Cheers,
Ben
Attachment: [application/pgp-signature] Message signed with OpenPGP signature.asc