Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116747
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
In-Reply-To: <1640910093.890171965@f721.i.mail.ru>
Date: Fri, 31 Dec 2021 10:19:54 +0300
Content-Transfer-Encoding: quoted-printable
Message-ID: <A27371F5-9292-40D0-A07E-01E9F6A7100E@cschneid.com>
References: <CABEW5qdH4w3JJpvZP4pD4R2tTvAFLiPZ_UNBnwA_38cZ4Mf8og@mail.gmail.com>
 <1640910093.890171965@f721.i.mail.ru>
To: internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int
 when using them as array-key
From: cschneid@cschneid.com (Christian Schneider)

Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov <nesk@xakep.ru>:
> I support this behavior fix because in its current form, due to a =
similar problem (almost?), all PSR-7 implementations contain bugs that =
violate RFC7230 (section 3.2:  =
https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus, =
physically, by the standard, all headers can have the name "0" (like =
=C2=AB0: value=C2=BB), but when stored inside implementations, it is =
converted to a string and a problem arises ($message->getHeaders() // =
returns array<int|string, string> instead of array<string, string>).
>=20
> To solve this problem without BC, it seems to me that Nikita's idea =
with =C2=ABdeclares=C2=BB is most suitable, like:
> ```
> <?php
> declare(strict_types=3D1, strict_array_keys=3D1);
> =20
> $array["0"] =3D 42; // array(1) { string(1) "0" =3D> int(42) }
> ```


I probably sound like a broken record but I'd strongly advise against it =
as it creates language dialects which means a line like
	$a["0"] =3D 42;
behaves differently depending on context, e.g. copying code from =
Stackoverflow might lead to subtle bugs and reminds me way too much of =
the ini-settings magic_quotes_gpc.

My take is that changing behavior is ok if it can go through a =
deprecation/warning phase but that is IMHO not the case here.

If people want to have different behavior I'd rather have a new type =
like
	$a =3D new Dict;
	$a["0"] =3D 42;
possibly with a short-hand for initialization.

Regards,
- Chris