Everything

php

Re: [RFC] Deprecations for PHP 8.6

php.internals

Garrett W.

63 days ago

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:
>
> 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
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

Tim Düsterhus

54 days ago

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 <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:
>>
>> 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

Garrett W.

48 days ago

On Thu, Jul 9, 2026 at 5:25 AM Tim Düsterhus <tim@bastelstu.be> wrote:

>
> 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 <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:
> >>
> >> 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

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.

Tim Düsterhus

48 days ago

Hi

On 2026-07-15 02:37, Garrett W. wrote:

> 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