Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127918
Message-ID: <b56286ec-d1ed-4057-b813-0155d6ca1208@bastelstu.be>
Date: Sun, 6 Jul 2025 15:35:16 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
To: Niels Dossche <dossche.niels@gmail.com>, internals@lists.php.net
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
 <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
Content-Language: en-US
In-Reply-To: <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/4/25 09:01, Niels Dossche wrote:
> First of all, that's a huge list of deprecations and I think we should tone down on that.
> Especially if a feature still has a purpose and is not harmful or buggy, then we should probably consider not deprecating it.

It's a long list, but many of the deprecations are just obvious 
follow-ups of a previous RFC or closely related.

As an example, I would consider all the `_close()` / `_free()` / 
`destroy()` function deprecations to be a single one in practice and 
then one that just fixes an inconsistency, since others are already 
deprecated. Similarly Reflection*::setAccessible() is a follow-up for a 
previous RFC that deferred the deprecation to reduce the impact on 
existing code.

Defining "harmful" is also complicated. Is making the language harder to 
learn for newcomers "harmful" (e.g. the case-with-semicolon one, which 
is just a tiny bit of syntax difference for the same thing)? Is allowing 
for confusing code (e.g. Reflection::setAccessible(false)) "harmful"?

In both cases, I'd say: Yes, that is harmful.

> Secondly, I'm tired of having to deal with useless deprecation messages.
> A lot of deprecation messages are completely useless for developers because they do not point to a reason or a replacement.
> That leaves you needing to look up the documentation, which is also incomplete.
> See https://github.com/php/php-src/issues/14320
> Therefore, any deprecation proposed in this RFC that does not explicitly list the deprecation message, I will vote no for.

I agree that having useful deprecation messages is important and I've 
just added a `trigger_error()` example to the PDO 'uri:' deprecation 
that I proposed. My other proposals already had the `#[\Deprecated]` 
attribute including the message.

> There are a few things I will vote no for:
> 
> * Deprecate semicolon after case in switch statement.
>    People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it.

See above. Also: The RFC seems to indicate that this is not actually 
used in practice.

> * Deprecate attributes applying to multiple class properties/constants.
>    On the edge, confusing yes, but it might break real code.

Since this is a recurring thing, I feel compelled to point out 
terminology: A deprecation in itself is not a breaking change.

> * Deprecate __debugInfo() returning null
>    Weird, especially as the docs say the return type is ": array", but not harmful.

I consider undocumented behavior to be harmful and in this case 
deprecating (and removing) the undocumented behavior seems to be better 
than adding another special case to the language that users need to 
learn about.

> * Deprecate passing spl_autoload_call() to spl_autoload_unregister()
>    This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. So what's the point really.
>    The behaviour may be weird, but notice that people won't do this by accident.

See above regarding "undocumented behavior". Also to my understanding 
this is not about "preventing workarounds", but rather removing this 
branch, which is just surprising behavior:

https://github.com/php/php-src/blob/677a1f80c86b7a5848985bf44714210d0b89900b/ext/spl/php_spl.c#L583-L590

Best regards
Tim Düsterhus