Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116827
Date: Thu, 06 Jan 2022 10:34:32 +0000
CC: PHP Internals List <internals@lists.php.net>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAOD_yv39XJRxHtJYopGA+ew2LnGy7zX6by1haAJzYj5J-mtgQA@mail.gmail.com>
References: <CABEW5qdH4w3JJpvZP4pD4R2tTvAFLiPZ_UNBnwA_38cZ4Mf8og@mail.gmail.com> <CAOD_yv39XJRxHtJYopGA+ew2LnGy7zX6by1haAJzYj5J-mtgQA@mail.gmail.com>
Message-ID: <3BC1462F-BC9D-43AF-B4C9-8D988067A5B6@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary=----J4UZQC0ZZEM2940OHZA44MZ4VFC0IO
Content-Transfer-Encoding: 7bit
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_RFC=3A_Stop_to_automatically_cast_nu?= =?US-ASCII?Q?meric-string_to_int_when_using_them_as_array-key?=
From: rowan.collins@gmail.com (Rowan Tommins)

------J4UZQC0ZZEM2940OHZA44MZ4VFC0IO
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6 January 2022 07:29:58 GMT, James Titcumb <james@asgrim=2Ecom> wrote:
>Just thinking out loud, being able to identify an array type might be a w=
ay
>forward here (using "syntax" already in use by static analysis tools in
>docblocks, for familiarity), e=2Eg=2E
>
>private array<string, mixed> $property;
>
>This might "turn off" the automatic type juggling behaviour, for example=
=2E
>If the existing strict_types=3D1 mode is on, this might fail:
>
>$this->property[3] =3D "hi";
>
>If strict_types=3D0 or not declared, the key would be cast to a string=2E


Yes, something similar occurred to me earlier, and I honestly think that s=
ome new types like this are the only way this can practically be solved=2E


>That said, I know there has been contentious discussion on this and the
>related topic of generics multiple times, so don't really want to stir up=
 a
>hornet's nest there=2E


It's not so much that generics are contentious, but that they're really, r=
eally hard to implement within the context of PHP's other features=2E It ge=
ts complicated really quickly when you need to verify parameter and return =
types, e=2Eg=2E to decide if a value of type SortedList<ChildClass> meets a=
 parameter constraint List<ParentClass>

Leaving that aside, though, an array type that has certain constraints on =
assignment might be workable=2E And a simple pair that only constrain their=
 keys could just be individually named rather than introducing generics=2E


As for the original suggestion, I think some people are underestimating ju=
st how disruptive changing this could be=2E The really big problem is that =
there is nothing to deprecate, very little to detect with static analysis t=
ools, and very confusing code if you want to support both versions=2E

The following would be perfectly valid PHP both before and after the behav=
iour change:

$a =3D [];
$a[42] =3D true;
$a['42'] =3D false;
$a[ (string)43 ] =3D true;
$a[ (int)'43' ] =3D false;

None of those lines is "wrong", in and of itself, so there's nothing to ma=
rk deprecated or warn about; but the result in current PHP is [42 =3D> fals=
e, 43 =3D> false]; and with the proposed change, the result would presumabl=
y be [42 =3D> true, '42' =3D> false, '43' =3D> true, 43 =3D> false]

I can't think of any way one could prepare for this change, other than put=
ting a string cast in front of every array index throughout an entire code =
base, *and* on every use of array_keys, foreach, etc that *reads* array key=
s=2E Unless someone can present a fully working migration plan, this would =
get a "no" vote from me=2E


Regards,

--=20
Rowan Tommins
[IMSoP]
------J4UZQC0ZZEM2940OHZA44MZ4VFC0IO--