[RFC] Add is_list(mixed $value): bool to check for list-like arrays

Hi Ben,

I think there are some places where 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.

Yes, that's correct.
These idiosyncrasies of php and unintuitive behaviors existed
prior to this RFC.

It's also confusing when reset($x) is not the same thing as $x[0]
on a non-empty array with keys 0..n-1 out of order if you're still learning php.

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.

It would simplify is_dict(array $x) to count($arr) > 0 && !is_list($arr),
and potentially improve performance.

There's already some ways is_* doesn't correspond to a data type

• is_numeric does not correspond to a data type.
• is_callable varies depending on the context where it's called for private methods.
• is_resource returns false if a resource is closed.
• is_file is checking for a path (and readability?) on disk, not a type.

If you do understand what the type checks are doing, it makes it easier to check type-safety-ness
in a script (e.g. if(!is_list(...)){ /*warn*/ } in a standalone script) or with external analyzers.

Thanks,
Tyson