Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112565
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <1b92dea2-667f-4de7-9de9-0aa41f56f81e@www.fastmail.com>
In-Reply-To: 
 <DM6PR07MB6618468A8C4A49818C4E2EB0F9C10@DM6PR07MB6618.namprd07.prod.outlook.com>
References: 
 <DM6PR07MB6618468A8C4A49818C4E2EB0F9C10@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Sun, 20 Dec 2020 11:08:11 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Add_is=5Flist(mixed_$value):_bool_to_check?=
 =?UTF-8?Q?_for_list-like_arrays?=
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Dec 19, 2020, at 7:43 PM, tyson andre wrote:
> Hi internals,
>=20
> I've created the RFC https://wiki.php.net/rfc/is_list
>=20
> This adds a new function `is_list(mixed $value): bool` that will retur=
n=20
> true
> if the type of $value is array and the array keys are `0 ..=20
> count($value)-1` in that order.
>=20
> It's well-known that PHP's `array` data type is rare among programming=
=20
> languages
> in that it supports both integer and string keys
> and that iteration order is important and guaranteed.
> (it is used for overlapping use cases - in many other languages, both=20=

> vectors/lists/arrays and hash maps are available)
>=20
> While it is possible to efficiently check that something is an array,
> that array may still have string keys, not start from 0, have missing=20=

> array offsets,
> or contain out of order keys.
>=20
> It can be useful to verify that the assumption that array keys are=20
> consecutive integers is correct,
> both for data that is being passed into a module or for validating dat=
a=20
> before returning it from a module.
> However, because it's currently inconvenient to do that, this has=20
> rarely been done in my experience.
>=20
> In performance-sensitive serializers or data encoders, it may also be=20=

> useful to have an efficient check to distinguish lists from associativ=
e=20
> arrays.
> For example, json_encode does this when deciding to serialize a value=20=

> as [0, 1, 2] instead of {=E2=80=9C0=E2=80=9D:0,=E2=80=9C2=E2=80=9D:1,=E2=
=80=9C1=E2=80=9D:1}
> for arrays depending on the key orders.
>=20
> Prior email threads/PRs have had others indicate interest in the=20
> ability to efficiently check
> if a PHP `array` has sequential ordered keys starting from 0
>=20
> https://externals.io/message/109760 =E2=80=9CAny interest in a list ty=
pe?=E2=80=9D
> https://externals.io/message/111744 =E2=80=9CRequest for couple memory=
=20
> optimized array improvements=E2=80=9D
> Implementation: https://github.com/php/php-src/pull/6070 (some=20
> discussion is in the linked PR it was based on)
>=20
> Thanks,
> - Tyson

Well, since I'm quoted... :-)

I'm fine with this, but have one question and one correction:

* If we do eventually end up with list/vec types, would the naming here =
conflict at all?  Or would it cause confusion and name collision?  (Inse=
rt name bikeshedding here.)

* The last quote, from me, has a small error.  The last sentence shouldn=
't be a bullet point but its own paragraph, after the list is complete.

--Larry Garfield