Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123696
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"
In-Reply-To: <GV1PR01MB10526755D1361D1E4CD285C46C2C82@GV1PR01MB10526.eurprd01.prod.exchangelabs.com>
Date: Thu, 20 Jun 2024 16:04:57 +0200
Cc: internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A5DE18ED-9733-4890-A4EF-5B8BED3F600E@gmail.com>
References: <CAPzBOBMidokE3xw251f+_qbCPAyQQRcN1WnyVF0xfuzaPBU3JA@mail.gmail.com>
 <9d28c9tOCChpWUcP1SFiFwtf2-w2XAtDzHsmM73myA7zfBsn7TxxEqs-VCnxRAgZjsk2TxS55owmM8wSLgBQL8LgeQLntUQ9toeLMkjTVx4=@gpb.moe>
 <GV1PR01MB10526755D1361D1E4CD285C46C2C82@GV1PR01MB10526.eurprd01.prod.exchangelabs.com>
To: Vincent de Lau <vincent@delau.nl>
From: claude.pache@gmail.com (Claude Pache)



> Le 20 juin 2024 =C3=A0 13:08, Vincent de Lau <vincent@delau.nl> a =
=C3=A9crit :
>=20
>=20
>=20
> From: Gina P. Banyard <internals@gpb.moe>
> Sent: Wednesday, June 19, 2024 5:08 PM
>>=20
>> On Tuesday, 18 June 2024 at 17:37, Robert Landers
>> <landers.robert@gmail.com> wrote:
>>=20
>>> Hello internals,
>>>=20
>>> [...]
>>>=20
>>> What are your thoughts?
>>=20
>> As self-proclaimed leading expert on PHP type juggling.
>> That it is a terrible idea with no gains whatsoever.
>> Renaming the declare statement does not improve the situation.
>>=20
>>> PS. Personally, I would rather unify non-strict and strict in some =
way
>>> that makes sense ... so, that route sounds nice too.
>>=20
>> See my old meta RFC: =
https://github.com/Girgias/unify-typing-modes-rfc
>>=20
>> It is a somewhat known hot take from mine that I think the =
strict_type
>> declare statement was a mistake. [1]
>> Mainly because it affects barely nothing in regard to the engine.
>>=20
>> I have written/co-authored multiple RFCs over the years to make the
>> default coercion mode less whack. [2][3][4][5][6][7]
>> And my container/offset RFC is in the same vein [8] which lead me =
into a
>> different rabbit hole then the one I was expecting to explore which =
is
>> addressing PHP's weird comparison semantics. [9]
>>=20
>> Therefore, I would rather we focus on *actually* fixing PHP's =
semantics,
>> than arguing about changing the name of something that shouldn't =
really
>> exist in the first place.
>=20
> Talking about 'going back in time' and sanitizing type coercion, I =
immediately had to think about the rejected 'Coercive Types for Function =
Arguments' RFC Zeev created as an alternative to the 'Scalar Type =
Declaration' RFC which was ultimately chosen and implemented.
>=20
> https://wiki.php.net/rfc/coercive_sth
>=20
> It seems that parts of what that RFC suggested have been implemented =
over time. In retrospect maybe this should have been the direction?

Hi,

The RFC you are pointing to was about introducing a new, more =
restrictive (and saner) set of automatic coercion rules in the context =
of function arguments *only*. For instance, `substr('xy', 1.2)` would =
have been deprecated, but `3 % 1.2` and `['x', 'y'][1.2]` would have =
continued to =E2=80=9Cwork=E2=80=9D (for some stretchy definition of =
=E2=80=9Cwork=E2=80=9D).

What has been implemented over time, is making the existing set of =
automatic coercion rules more restrictive (and saner) in *all* contexts. =
For instance, all of `substr('xy', 1.2)`,  `3 % 1.2` and `['x', =
'y'][1.2]` are deprecated.

=E2=80=94Claude