Re: [RFC] Deprecate Fuzzy Type Casts and Allow Stringable in Strict Mode

From: Date: Tue, 27 Jan 2026 12:13:40 +0000
Subject: Re: [RFC] Deprecate Fuzzy Type Casts and Allow Stringable in Strict Mode
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-129941@lists.php.net to get a copy of this message
On Tue, Jan 27, 2026, at 12:54, Lynn wrote: > > > On Fri, Jan 23, 2026 at 3:17 PM Alexandre Daubois <alex.daubois+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. >> >> > Does this behavior als affect parameters being passed in a non-strict fashion? Because >> > then I don't see a realistic migration path within the next decade for this application. >> >> This behavior already exists and forbids such casts, see >> https://3v4l.org/WQJPv#vnull. > > Thanks for your reply! > > 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 unknown break. I do not have voting power, so all I can > give is my opinion. > > As an alternative, what about this? It could be the best of both worlds where the new behavior > is explicit: > ```php > $var = (int) '123test'; // still works, nothing changes, becomes an ^s…ฺ¨h¹™ > -[¯(int) 123 > int $var = '123test'; // follows the proposed rules, errors because it's not a > value that's a valid integer > int $var = '123'; // works because it's a valid integer format, becomes (int) > 123 > int $var = (int) '123test'; // becomes (int) 123, existing behavior > ``` > 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. > > Bonus: > ```php > int|null $var = '123test'; // could result in null > instead of throwing, similar to the Enum tryFrom. > > // could enable > MyEnum $foo = '123test'; > MyEnum|null $bar = '123test'; > > // translates to > $foo = MyEnum::from('123test'); > $bar = MyEnum::tryFrom('123test'); > ``` > > 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 int|null $var = "123test"; (https://3v4l.org/C0uaK/rfc#vgit.master) would be a TypeError. Less special cases means less bugs and less things to remember. — Rob

« previous php.internals (#129941) next »