On Fri, Jan 23, 2026 at 3:17 PM Alexandre Daubois < [email protected]> 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 `(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.
