Hi Anton, Le ven. 23 janv. 2026 à 15:59, Anton Smirnov <[email protected]> a écrit : > While I agree that this code likely indicates some form of broken logic, > this code still needs a clear migration path, so introducing something > like fuzzy_int() function with the old behavior I'd say is expected.
I have concerns about introducing fuzzy_int() as a migration path: 1. It would essentially codify the current problematic behavior into a new API, making it "official" rather than fixing the underlying issue 2. It adds yet another conversion mechanism to an already complex landscape (casts, type coercion, filter_var, etc.) 3. Developers who truly need to extract integers from strings like "123abc" can use explicit parsing. This makes the intent explicit: "I'm extracting a number from potentially dirty input", rather than relying on cast semantics that differ from type validation. > Second, there should be a time frame where an old and a new way can > coexist so deprecating it in 8.x feels a bit rushed. To me a perfect > migration would be something like I understand the desire for a longer migration period. However, I'd argue that: 1. The current timeline (8.6 deprecation then 9.0 TypeError) provides 2-4 years depending on update cycles, which aligns with how we've handled other significant deprecations 2. Deprecation warnings in 8.6 give clear signals about what needs fixing 3. Static analysis tools (PHPStan, Psalm or any other tool) can detect these patterns immediately, even before upgrading to 8.6 — Alexandre Daubois
