Thanks for your comments!
> How would array_shift(), array_merge(array, list) ... be handled? Would
they return lists or arrays?
I think they would return lists where appropriate – Psalm & Phan already
infer some of that behaviour, adding runtime support would be an
undertaking, but not impossible.
> References to list typed properties may cause problems...
I don't see this as being any different to how integer typed properties
work under float addition (as below) – we'd just not allow any modification
that violated the list type.
class X { public int $i = 0; }
$x = new X();
$x->i += 2.3;
echo $x->i; // 2, not 2.3
With declare(strict_types=1), the above is a fatal error – the same would
be true for operations that violated list typed properties
> Having them limited to param type and return type checks
Would be happy for that compromise if the above proved confusing, or
difficult to implement
On Tue, 21 Apr 2020 at 20:18, tyson andre <tysonandre...@hotmail.com> wrote:
> 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
