Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129909
Date: Sat, 24 Jan 2026 13:37:00 +0000
To: Alexandre Daubois <alex.daubois+php@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable in Strict Mode
Message-ID: <LBSH-YjRN0Epj8UlZIU5J7YXzoVEe9bFO95aIKFwOxzRlJBTFN52gts4BSyABIln0BI46sRf15qzlN3kSHnWAq6Z86faBszxy_gU3okMs2U=@gpb.moe>
In-Reply-To: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Friday, 23 January 2026 at 10:51, Alexandre Daubois <alex.daubois+php@gm=
ail.com> wrote:

> Hello everyone,
>=20
> Before going further with our already under discussion RFC about
> nullable casts, Nicolas Grekas and I would like to present this new
> RFC about deprecating fuzzy casts, and adding support for Stringable
> in string parameters when using strict mode.
>=20
> RFC: https://wiki.php.net/rfc/deprecate-fuzzy-casts
>=20
> Thanks,
>=20
> =E2=80=94 Alexandre Daubois

Hello Alexandre,

I know we had some preliminary offline discussions about this RFC,
but having the final document in front of me, I feel you are mixing 3 diffe=
rent RFCs in one.
And none of them are fully fleshed out within this single document.

I see that you've already replied to Larry that you're going to spin out th=
e Stringable change into its own RFC, which I think is good.
However, even when just talking about the casting operators the discussion =
is muddled.
You are grouping the transformation between scalar types (string, int, floa=
t, bool) and how they can truncate/coerce data with a possible loss of info=
rmation on one hand,
and talking about the (object) cast on the other hand, which is a cast to a=
 "structured" type.

While I agree that the (object) cast is definitely strange on scalar types,=
 I also don't see why keeping (object) for casting arrays makes that much m=
ore sense?
And why do you not talk about the (array) cast at all?
Both of these casts are two sides of the same coin, and IMHO should both be=
 deprecated outright, due to their confusing semantics.
Yes, I know Symfony uses the (array) cast a lot, but the get_mangled_object=
_vars() function has existed long enough for it to replace the usage of (ar=
ray) on objects.

And even the aspect about the fuzzy casts feels incomplete to me, you do no=
t talk about the (bool) or (string) cast (and relevant boolval()/strval() f=
unctions) are these affected by your RFC change?
Because casting a float to a string depends on the precision INI setting, s=
ee: https://3v4l.org/5GJWh
Which _feels_ like a fuzzy cast to me, although this is just PHP's usual fl=
oat to string coercion semantics.
You also mention that the `(int) 12.5` fuzzy cast is covered by my "Depreca=
te implicit non-integer-compatible float to int conversions" RFC [1],
but this is not the case. See: https://3v4l.org/3AZOd#vnull
As I specifically did *not* affect the behaviour of the casting operators i=
n this RFC, nor in my prior "Saner numeric strings" RFC.
The reason being is that many people were concerned about the impact on leg=
acy codebase, or codebase that utilized the long-standing truncation behavi=
our.

Moreover, at no point do you describe if NULL would still be accepted for t=
ype casting.
Because if you do, then it would not follow the behaviour of scalar type ch=
ecks which rejects NULL.
And what would happen to these scalar casts if a different version of the "=
Deprecate type juggling to and from bool type within the function type jugg=
ling context" RFC [3] passes?

Overall, it feels this proposal is trying to work around the "mindless" usa=
ge of strict_types, to which my opinion and solution is to just remove it.
I very much understand the appeal of trying to fix the problem at the root,=
 but I'm not sure if this would pass,
considering that adding various "parse_T()" functions that exposes the ZPP =
behaviour might just be more sensible.


Best regards,

Gina P. Banyard

[1] https://wiki.php.net/rfc/implicit-float-int-deprecate
[2] https://wiki.php.net/rfc/saner-numeric-strings
[3] https://wiki.php.net/rfc/deprecate-function-bool-type-juggling