Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129903
Precedence: list
MIME-Version: 1.0
References: <CAMU7ir+1VfQCiSVG0BjN5V+upNU2kU+a_rKDXO1=Ahu3ndmOGg@mail.gmail.com>
 <CANS-=pfCasTNSAMSdL8ajJMnrwNpfvbEOoQTQhAQ=X73iG+_tw@mail.gmail.com>
 <CAMU7irLgsMCzHsQDD6Ok2zJZsNyV7LF-PHotzqvSGRAkN9bovg@mail.gmail.com> <31563ed1-ac44-47ef-9fca-3ebbfc567ba5@sandfox.me>
In-Reply-To: <31563ed1-ac44-47ef-9fca-3ebbfc567ba5@sandfox.me>
Date: Fri, 23 Jan 2026 18:05:09 +0100
Message-ID: <CAMU7irLSn2KhhyFotxaqBTS6MYiHmEZH69gAELXrmRRvKHZLqA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Fuzzy Type Casts and Allow Stringable
 in Strict Mode
To: Anton Smirnov <sandfox@sandfox.me>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.daubois+php@gmail.com (Alexandre Daubois)

Hi Anton,

Le ven. 23 janv. 2026 =C3=A0 15:59, Anton Smirnov <sandfox@sandfox.me> a =
=C3=A9crit :
> 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 t=
hat:

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

=E2=80=94 Alexandre Daubois