Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127936
Date: Mon, 07 Jul 2025 15:48:55 +0000
To: Niels Dossche <dossche.niels@gmail.com>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
Message-ID: <1yx0GE3X9ysln_bTni-MXXWHDPtPXcmPKaO6bySOiGjkjyFCMCB_wKz67XuEt_sifpZC63kkzreaNt4Trlrpir4MKRCgfkBV0X00cvQq1dA=@gpb.moe>
In-Reply-To: <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe> <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Friday, 4 July 2025 at 08:04, Niels Dossche <dossche.niels@gmail.com> wr=
ote:

> Hi
>=20
> First of all, that's a huge list of deprecations and I think we should to=
ne 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.

The list of deprecation being "huge" is a consequence of more people workin=
g on php-src.
We previously also had "large" deprecation RFCs like the one for 8.1, with =
some deprecations dropped.
See: https://wiki.php.net/rfc/deprecations_php_8_1

Moreover, "harmful" is very much in the eyes of the beholder.

> Secondly, I'm tired of having to deal with useless deprecation messages.
> A lot of deprecation messages are completely useless for developers becau=
se they do not point to a reason or a replacement.
> That leaves you needing to look up the documentation, which is also incom=
plete.
> 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 have added the deprecations messages for my own proposals,
but I don't see this as a valid reason to vote against one.
The deprecation message is very much an implementation detail, and we shoul=
d be able to improve it at any point.
This is also *much* easier now that we can use the #[Deprecated] attributes=
 on the majority of internals symbols, as that was one of the major limitat=
ions.


> There are some things in the list I don't care about or I don't have a lo=
t of insight of its uses in, and I will abstain for voting on them.
>=20
> There are a few things I will vote no for:
>=20
> [...]
>=20
> * 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 th=
is on array offsets but not on the function.

I am slightly confused by what you mean by "allowing this on array offsets =
but not on the function".
However, null is not accepted by functions that accept scalar types, and bo=
ol would neither if my other RFC is approved.
Moreover, a type declaration of int|string accepted Stringable objects, how=
ever array offsets do not accept objects at all.

> * Deprecate _debugInfo() returning null
> Weird, especially as the docs say the return type is ": array", but not h=
armful.

Again, harmful here is very subjective.
But as this is not my proposal, I will not comment further on it.

> [...]
>=20
> * Deprecate passing spl_autoload_call() to spl_autoload_unregister()
> This is very ad hoc, and as Ilija pointed out, we can't prevent workaroun=
ds for this. So what's the point really.
> The behaviour may be weird, but notice that people won't do this by accid=
ent.

As replied to Ilija, and as Tim already mentioned, the workaround do NOT be=
have the same way as passing the function directly.

> * Deprecate passing null to readdir(), rewinddir(), and closedir()
> Dubious but not really harmful I think.

I disagree that relying on implicit global state is not harmful.

> * Based on Derick's comments I will vote no on the ext/filter deprecation=
s. I was already going to vote no on the filter* functions though.

I have removed the functions anyway, however FILTER_DEFAULT is an incredibl=
y problematic name, and not passing a filter is also problematic, so those =
remain on the RFC.

> * Deprecate driver specific PDO constants and methods
> Too early.

I disagree with too early as the migrations for the constants is extremely =
easy and can be done by tools like Rector (or hell even sed if you feel adv=
enturous)
and the methods are effectively a hack on the PDO class which is already we=
ird enough.


Best regards,

Gina P. Banyard