Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129892
Feedback-ID: id5114917:Fastmail
Date: Fri, 23 Jan 2026 14:54:49 +0000
To: PHP internals list <internals@lists.php.net>
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_=5BRFC=5D_Deprecate_Fuzzy_Type_?=
 =?US-ASCII?Q?Casts_and_Allow_Stringable_in_Strict_Mode?=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
Message-ID: <EDFD449E-59F4-4DFA-B348-B1650A745DB1@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 23 January 2026 10:48:45 GMT, Alexandre Daubois <alex=2Edaubois+php@gmai=
l=2Ecom> wrote:
>Hello everyone,
>
>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=2E
>
>RFC: https://wiki=2Ephp=2Enet/rfc/deprecate-fuzzy-casts


Hi Alexandre,

I am strongly against the Stringable part of this=2E

It would mean users who have explicitly asked for no type coercion would g=
et silent type coercion=2E It would mean that a string parameter in mode 1 =
would still reject an integer 42, but would *accept* new BcMath\Number(42)=
=2E I can't see how that makes sense=2E

-

My thoughts on "fuzzy casts" are more nuanced=2E

I do think PHP needs some functions or syntax for "validating" casts, but =
I'm not convinced they should *replace* our existing casts=2E

Not only would it break the huge amount of code out there which assumes th=
at a cast will always return a result rather than an error, I think that is=
 a perfectly valid use case=2E It is often useful to say "take this string,=
 and return an integer if it's int-like, or a default value of 0 if not"=2E=
 Although they're not perfect, that's roughly what our existing casts provi=
de=2E

I can see an argument for making (int)"123hello" evaluate to 0, rather tha=
n 123; but even that would be a confusing BC break for a lot of application=
s=2E

As I've said elsewhere, I think the right approach to this is to design a =
new set of cast operations, with a more extendable syntax=2E They can have =
more clearly defined rules for "int-like string" etc, and different modes/v=
ariants for use cases like "error on failure" vs "default value on failure"=
=2E



Rowan Tommins
[IMSoP]