Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129941
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 27 Jan 2026 13:13:40 +0100
To: Lynn <kjarli@gmail.com>, "Alexandre Daubois" <alex.daubois+php@gmail.com>
Cc: "PHP internals list" <internals@lists.php.net>
Message-ID: <411b1964-eacd-475f-a9f5-2a954b6d30df@app.fastmail.com>
In-Reply-To: 
 <CANS-=pd2+iqav=VKgON6R6XAs4rodNf+5gCgH=7EUPbTum3wWA@mail.gmail.com>
References: 
 <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
 <CANS-=pfCasTNSAMSdL8ajJMnrwNpfvbEOoQTQhAQ=X73iG+_tw@mail.gmail.com>
 <CAMU7irLgsMCzHsQDD6Ok2zJZsNyV7LF-PHotzqvSGRAkN9bovg@mail.gmail.com>
 <CANS-=pd2+iqav=VKgON6R6XAs4rodNf+5gCgH=7EUPbTum3wWA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable in Strict
 Mode
Content-Type: multipart/alternative;
 boundary=225418ba83ce434282f0442e0f59a6e1
From: rob@bottled.codes ("Rob Landers")

--225418ba83ce434282f0442e0f59a6e1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 27, 2026, at 12:54, Lynn wrote:
>=20
>=20
> On Fri, Jan 23, 2026 at 3:17=E2=80=AFPM Alexandre Daubois <alex.dauboi=
s+php@gmail.com <mailto:alex.daubois%2Bphp@gmail.com>> wrote:
>> I understand the concern about legacy code. However, if code relies on
>> `(int) "123abc"` silently returning `123`, this represents a data
>> integrity issue that would benefit from being made explicit. The
>> deprecation period exists specifically to help identify and address
>> these cases.
>>=20
>> > Does this behavior als affect parameters being passed in a non-stri=
ct fashion? Because then I don't see a realistic migration path within t=
he next decade for this application.
>>=20
>> This behavior already exists and forbids such casts, see
>> https://3v4l.org/WQJPv#vnull.
>=20
> Thanks for your reply!=20
>=20
> I've given it a bit more thought and while I 100% agree with the reaso=
ns given, I'm still afraid this change is too big of an unknown break. I=
 do not have voting power, so all I can give is my opinion.
>=20
> As an alternative, what about this? It could be the best of both world=
s where the new behavior is explicit:
> ```php
> $var =3D (int) '123test'; // still works, nothing changes, becomes an =
`(int) 123`
> int $var =3D '123test'; // follows the proposed rules, errors because =
it's not a value that's a valid integer
> int $var =3D '123'; // works because it's a valid integer format, beco=
mes (int) 123
> int $var =3D (int) '123test'; // becomes (int) 123, existing behavior
> ```=20
> This way nothing breaks and the casting remains what it is, but we can=
 still enforce correct types. I know the 3rd line might be controversial=
, but it makes it an opt-in instead of opt-out feature and errors can be=
 thrown as of day 1.
>=20
> Bonus:
> ```php
> int|null $var =3D '123test'; // could result in `null` instead of thro=
wing, similar to the Enum tryFrom.
>=20
> // could enable
> MyEnum $foo =3D '123test';
> MyEnum|null $bar =3D '123test';
>=20
> // translates to
> $foo =3D MyEnum::from('123test');
> $bar =3D MyEnum::tryFrom('123test');
> ```
>=20
> `from` and `tryFrom` could be taken as base for custom cast functions,=
 but that's probably a whole different can of worms.

I kinda like this idea, but it would be nice to follow the same rules we=
 have with function calls, thus=20

int|null $var =3D "123test"; (https://3v4l.org/C0uaK/rfc#vgit.master)

would be a TypeError. Less special cases means less bugs and less things=
 to remember.

=E2=80=94 Rob
--225418ba83ce434282f0442e0f59a6e1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Tue, Jan =
27, 2026, at 12:54, Lynn wrote:</div><blockquote type=3D"cite" id=3D"qt"=
 style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><br></div><div><br></div><=
div class=3D"qt-gmail_quote qt-gmail_quote_container"><div dir=3D"ltr" c=
lass=3D"qt-gmail_attr">On Fri, Jan 23, 2026 at 3:17=E2=80=AFPM Alexandre=
 Daubois &lt;<a href=3D"mailto:alex.daubois%2Bphp@gmail.com">alex.dauboi=
s+php@gmail.com</a>&gt; wrote:</div><blockquote class=3D"qt-gmail_quote"=
 style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:=
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204, 204, 204);padding-left:1ex;"><div>I understand the concern about =
legacy code. However, if code relies on</div><div> `(int) "123abc"` sile=
ntly returning `123`, this represents a data</div><div> integrity issue =
that would benefit from being made explicit. The</div><div> deprecation =
period exists specifically to help identify and address</div><div> these=
 cases.</div><div> <br></div><div> &gt; Does this behavior als affect pa=
rameters being passed in a non-strict fashion? Because then I don't see =
a realistic migration path within the next decade for this application.<=
/div><div> <br></div><div> This behavior already exists and forbids such=
 casts, see</div><div> <a href=3D"https://3v4l.org/WQJPv#vnull" rel=3D"n=
oreferrer" target=3D"_blank">https://3v4l.org/WQJPv#vnull</a>.</div></bl=
ockquote><div><br></div><div><div>Thanks for your reply!&nbsp;</div><div=
><br></div><div>I've given it a bit more thought and while I 100% agree =
with the reasons given, I'm still afraid this change is too big of an un=
known break. I do not have voting power, so all I can give is my opinion=
.</div></div><div><br></div><div>As an alternative, what about this? It =
could be the best of both worlds where the new behavior is explicit:</di=
v><div>```php</div><div>$var =3D (int) '123test'; // still works, nothin=
g changes, becomes an `(int) 123`</div><div>int $var =3D '123test'; // f=
ollows the proposed rules, errors because it's not a value that's a vali=
d integer</div><div>int $var =3D '123'; // works because it's a valid in=
teger format, becomes (int) 123</div><div>int $var =3D (int) '123test'; =
// becomes (int) 123, existing behavior</div><div>```&nbsp;</div><div>Th=
is way nothing breaks and the casting remains what it is, but we can sti=
ll enforce correct types. I know the 3rd line might be controversial, bu=
t it makes it an opt-in instead of opt-out feature and errors can be thr=
own as of day 1.</div><div><br></div><div>Bonus:</div><div>```php</div><=
div>int|null $var =3D '123test'; // could result in `null` instead of th=
rowing, similar to the Enum tryFrom.</div><div><br></div><div>// could e=
nable</div><div>MyEnum $foo =3D '123test';</div><div>MyEnum|null $bar =3D=
 '123test';</div><div><br></div><div>// translates to</div><div>$foo =3D=
 MyEnum::from('123test');</div><div>$bar =3D MyEnum::tryFrom('123test');=
</div><div>```</div><div><br></div><div>`from` and `tryFrom` could be ta=
ken as base for custom cast functions, but that's probably a whole diffe=
rent can of worms.</div></div></div></blockquote><div><br></div><div>I k=
inda like this idea, but it would be nice to follow the same rules we ha=
ve with function calls, thus&nbsp;</div><div><br></div><div>int|null $va=
r =3D "123test"; (<a href=3D"https://3v4l.org/C0uaK/rfc#vgit.master">htt=
ps://3v4l.org/C0uaK/rfc#vgit.master</a>)<br></div><div><br></div><div>wo=
uld be a TypeError. Less special cases means less bugs and less things t=
o remember.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</=
div></body></html>
--225418ba83ce434282f0442e0f59a6e1--