Hi
It seems your email might've been missed, maybe because it didn't
properly thread due to the absence of the necessary headers. You might
want to check your email client.
On 2026-06-30 01:51, Garrett W. wrote:
On Mon, Jun 22, 2026 at 8:13 AM Gina P. Banyard <[email protected]>
wrote:
Hello internals,
It is this time of year again where we proposed a list of deprecations
to add in PHP 8.6:
https://wiki.php.net/rfc/deprecations_php_8_6
I've been reading over this page and I've noticed several comma
splices in proposed deprecation notices and warnings. I don't have a
I'm not a native speaker, so I'm not 100% sure what you mean by “comma
splices”. If you mean that there is a comma in front of “use” in
“Deprecated: Function is_double() is deprecated, use is_float() instead”
this is an artifact of how PHP’s error messages don't include include a
dot at the end of the message so that they embed nicely into the
standard printer that appends “in foo.php on line 123”. And for function
deprecations specifically the message is pre-formatted with the
“Function foo() is deprecated” and the “use is_float() instead” part is
the $reason property on the #[\Deprecated] attribute.
So the phrasing of the error message is consistent with how error
messages in PHP are typically phrased.
Hope that makes sense and answers your question.
corrections here so someone else can make them. But would this kind of
thing normally be caught/handled at the PR stage, or here? (Or both?)
The deprecation messages can still change during PR review (or even
later), there is explicitly no BC guarantees for those. They are
primarily listed in the RFC, because it allows for double-checking that
the message accurately represents the reasoning behind the proposal and
that it includes all the necessary information to be actionable by the
user.
Best regards
Tim Düsterhus
