Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109777
MIME-Version: 1.0
References: <CAKuGYLSHXG=QSjPT5TCgf2KV-D+cMt=s4++sw38wy3Hwt1BuqQ@mail.gmail.com>
 <DM6PR07MB661892CBDA187461D8B1E640F9D50@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB661892CBDA187461D8B1E640F9D50@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Wed, 22 Apr 2020 12:01:20 -0400
Message-ID: <CAKuGYLS-1x3_ZyU4zoKc=DhQ==HQCw+rMz17UAK1udU02DS+iQ@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f8ca6405a3e33e39"
Subject: Re: [PHP-DEV] Any interest in a list type?
From: matthewmatthew@gmail.com (Matthew Brown)

--000000000000f8ca6405a3e33e39
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=93 Psalm & Phan al=
ready
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) =E2=80=93 we'd just not allow any modi=
fication
that violated the list type.

class X { public int $i =3D 0; }
$x =3D new X();
$x->i +=3D 2.3;
echo $x->i; // 2, not 2.3

With declare(strict_types=3D1), the above is a fatal error =E2=80=93 the sa=
me 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 <tysonandre775@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) migh=
t
> not return true in the final implementation you decide on, maybe wait. (y=
ou
> 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 i=
n
> 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 =3D &$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 an=
d
> return types may work.
> - Having them limited to param type and return type checks (including som=
e
> internal global function return types) would be how I'd prefer it (instea=
d
> 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) =3D $array` or `foreach ($x as list($y)) to avoid conf=
usion
>   (even though it's currently unambiguous, and that probably will remain
> unambiguous)
>
> - Tyson

--000000000000f8ca6405a3e33e39--