Hello internals,
It is this time of year again where we proposed a list of deprecations to add in 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
wiki account, much less edit privs, so in accordance with the
instructions on the wiki's Register page, I was thinking of posting my
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?)
--
Garrett Whitehorn
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 Mon, Jun 22, 2026 at 8:13 AM Gina P. Banyard internals@gpb.moe
wrote:Hello internals,
It is this time of year again where we proposed a list of deprecations
to add in 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
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 Mon, Jun 22, 2026 at 8:13 AM Gina P. Banyard internals@gpb.moe
wrote:Hello internals,
It is this time of year again where we proposed a list of deprecations
to add in 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 aI'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: Functionis_double()is deprecated, useis_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 “useis_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
Thanks for the reply. I'm not complaining about the lack of a full
stop so much, but like in the example you called out, a comma is less
appropriate there than a semicolon, em dash, or similar. If it were
me, I'd just use a semicolon in those cases.
--
Garrett W.
Hi
Thanks for the reply. I'm not complaining about the lack of a full
stop so much, but like in the example you called out, a comma is less
appropriate there than a semicolon, em dash, or similar. If it were
me, I'd just use a semicolon in those cases.
Okay, in that case - even though there is explicitly no guarantee in the
stability of error messages from PHP itself - changing it to a semicolon
would nevertheless be a break in expectations of users who have already
leveraged the #[\Deprecated] attribute with a $reason.
Best regards
Tim Düsterhus