Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127873
Message-ID: <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
Date: Fri, 4 Jul 2025 09:01:52 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
To: internals@lists.php.net
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
Content-Language: en-US
In-Reply-To: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
From: dossche.niels@gmail.com (Niels Dossche)

Hi

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.

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.

There are some things in the list I don't care about or I don't have a lot of insight of its uses in, and I will abstain for voting on them.

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.

* Deprecate attributes applying to multiple class properties/constants.
  On the edge, confusing yes, but it might break real code.

* Deprecate using values of type null and bool as array offsets and when calling array_key_exists()
  Deprecating this would make the language more inconsistent by allowing this on array offsets but not on the function.

* Deprecate __debugInfo() returning null
  Weird, especially as the docs say the return type is ": array", but not harmful.

* Deprecate ReflectionParameter::allowsNull()
  This shorthand doesn't hurt anybody, and is convenient, I don't see the point in deprecating it.

* 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.

* Deprecate passing null to readdir(), rewinddir(), and closedir()
  Dubious but not really harmful I think.

* Based on Derick's comments I will vote no on the ext/filter deprecations. I was already going to vote no on the filter_* functions though.

* Deprecate driver specific PDO constants and methods
  Too early.

Kind regards
Niels