Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123671
Precedence: bulk
MIME-Version: 1.0
References: <CAPzBOBMidokE3xw251f+_qbCPAyQQRcN1WnyVF0xfuzaPBU3JA@mail.gmail.com>
 <6b07cb4b-13bc-4e63-8834-fc782faab01c@rwec.co.uk>
In-Reply-To: <6b07cb4b-13bc-4e63-8834-fc782faab01c@rwec.co.uk>
Date: Wed, 19 Jun 2024 10:30:45 +0200
Message-ID: <CAPzBOBPis8Gu6Wn4ugLWVbXX6uY1K-4vg8UXjd1zLmr=qscTbA@mail.gmail.com>
Subject: Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Tue, Jun 18, 2024 at 10:46=E2=80=AFPM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> On 18/06/2024 17:37, Robert Landers wrote:
>
> One thing is clear is that "strict types" may be a bit of poor word
> choice and gives people a false sense of security that it is "safe" or
> "more correct" when this obviously isn't true.
>
>
> I totally agree with this sentiment. I don't think it should be called "s=
trict", and I don't think it should be "on or off" either.
>
> If I had a time machine, I'd propose something like:
>
> declare(scalar_args=3Dcoerce);
> declare(scalar_args=3Derror);
>
> Or perhaps:
>
> declare(coerce_scalar_args=3Dif_safe);
> declare(coerce_scalar_args=3Dnever);
>

This is nice. I like it :)

>
>
> But...
>
>
> Thus, I'd like to propose, for PHP 9, simply renaming it...
>
>
> I'm not sure the pain is worth it. We'd have to introduce support gradual=
ly, probably not phasing out the old name until 10.0 at the earliest, so yo=
u'd just end up with more confusion with people not understanding if they w=
ere the same thing, which one to use in which version, etc.
>

I honestly don't know how the deprecation would work, or what makes
sense. Supporting both makes sense and as long as the behavior stays
exactly the same, and they are both set to the same thing, that would
probably be fine for awhile. Is it confusing... I wouldn't find it
confusing unless I was working on something that supported <9 and >9
and eventually 8.x will EoL and then it won't be so confusing anymore.

>
> Perhaps it might even be worth adding a secondary vote to flip the
> default, such that if you want to "old" behavior back
>
>
> You're falling into the same trap you're describing: assuming that strict=
_types=3D0 is an "older" mode, or a "worse" one. Both modes were introduced=
 at exactly the same time, as a direct choice to users between two differen=
t styles, which had been proposed in competing RFCs.
>
> Changing the default, and the name, but keeping the same behaviour, would=
 just be a huge mess.
>
>
> Personally, I would rather unify non-strict and strict in some way that m=
akes sense
>
>
> I think this is where we should be focussing our attention. We've had som=
e great RFCs over the last few years tightening up some of the weirder exce=
sses of PHP's type juggling system.

I've been mulling this around in my head last night and this morning.
I think I have something that makes sense, based mostly on information
loss. Essentially, an int could become a float (within some limits),
but a float can only become an int if it is an int itself. The same
concept of a string, where "123test" couldn't become a number because
"test" would be lost. Booleans are tricky, but I'd be inclined to keep
it as-is; otherwise, the BC break would be unbearable.

I think something like that would logically make sense. Whether or not
it would be feasible to implement in a performant way, I have no idea
(but it would be nice to clean up that area of the C code since it's a
bit of a tangle, IMHO). Interestingly, we could still do normal
coercion but just warn when there is information loss. Then, people
can ignore/catch those warnings and do whatever they want with them.
If information loss is what you want and you want to get rid of the
warning, you can simply add an explicit cast, but it would be nice
also to adjust casting so you can do

(int|null) $value; // or (?int) $value

so null won't be cast to zero. But that should probably be a totally
separate RFC and out of scope atm.

>
> With a tight enough definition of "numeric string" and other coercible va=
lues, I think "mode 0" could be strict enough that "mode 1" wouldn't feel s=
o necessary.
>
> Then again, I was broadly in favour of the original coercive-only proposa=
l for scalar type parameters, and there are those who felt strongly on the =
other side. The debate was extremely heated, and I'm not in a hurry to reop=
en it.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]

Robert Landers
Software Engineer
Utrecht NL