Re: Any interest in a list type?
| From: | tyson andre | Date: | Wed, 22 Apr 2020 00:18:28 +0000 |
| Subject: | Re: Any interest in a list type? | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109767@lists.php.net to get a copy of this message | ||
Miscellaneous thoughts on this:
- Working to have a vote on https://github.com/php/php-src/pull/4886 might
be a good first step, and something I was personally interested in seeing in 8.0-dev.
However, in the event you can't rule out that is_array($listParam) might not return true in
the final implementation you decide on, maybe wait. (you said it'd be a subtype, and it seems
like a lot of code would break, so that seems unlikely)
- How would array_shift(), array_merge(array, list), array_intersect, etc., preg_match(), etc be
handled? Would they return lists or arrays?
- I'd really have liked to see data structures such as sets, variable-length vectors, etc. in
core natively available as objects (or other types, but objects seemed the most practical).
Right now, there's php-ds https://www.php.net/manual/en/book.ds.php , but
if I wanted to use vec/list in an application/library that was used in a wide variety of places,
I'd really rather have something in core. (the drawbacks of using a polyfill would outweigh the
performance benefits for a small fraction of adopters)
- If those data types were natively available, maybe opcache and/or the jit could use specialized
opcodes to reduce the overhead of offsetGet, etc., if the class was known.
- References to list iyped properties
class X { public list $list; } $x->list =
&$localVar; unset($localVar[1]); may cause problems in implementation details if
they're a subtype of arrays.
Forbidding them in typed properties and limiting the type to params and return types may work.
- Having them limited to param type and return type checks (including some internal global function
return types) would be how I'd prefer it (instead of adding a separate type elsewhere)
PHP already has special handling for iterable/callable.
- Future scope of a list type hint might be to add a deprecation notice for list ($x, $y) =
$array or `foreach ($x as list($y)) to avoid confusion
(even though it's currently unambiguous, and that probably will remain unambiguous)
- Tyson