Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127956
To: "'Gina P. Banyard'" <internals@gpb.moe>,
	"'PHP internals'" <internals@lists.php.net>
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
In-Reply-To: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
Subject: RE: [PHP-DEV] [RFC] Deprecations for PHP 8.5
Date: Tue, 8 Jul 2025 14:14:31 +0300
Message-ID: <01ba01dbeff9$7aaffa50$700feef0$@glaive.pro>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQEX/jEFEpPiC9fa1q28fKEkZPoaCrWv8JhA
Content-Language: lv
From: juris@glaive.pro ("Juris Evertovskis")

Hi,

I'd like to add a bit to the harmful/useful debate.

While writing a `->setAccessible(true)` is not harmful per se, it's a =
clear indication one is following an outdated example/tutorial. New code =
should never contain it, not even for consistency (which could be argued =
for `__sleep()` if your codebase already has a couple of those). I would =
label a deprecation message for `setAccessible` as useful.=20

A semicolon for the switch cases, on the other hand, seems more like an =
easter egg and I'd love for it to stay just so PHP could keep that side =
of it's personality. I have similar feelings for `5d9` slowly =
incrementing to `6`. It's funny and unused and an excellent trivia =
piece. It would be sad to add a "but it no longer works since 8.5" to =
the stories.

BR,
Juris

-----Original Message-----
From: Gina P. Banyard <internals@gpb.moe>=20
Sent: Wednesday, July 2, 2025 10:56 PM
To: PHP internals <internals@lists.php.net>
Subject: [PHP-DEV] [RFC] Deprecations for PHP 8.5

Hello internals,

It is this time of year again where we proposed a list of deprecations =
to add in PHP 8.5:

https://wiki.php.net/rfc/deprecations_php_8_5

As a reminder, this list has been compiled over the course of the past =
year by various different people.

And as usual, each deprecation will be voted in isolation.

We still have a bit of time buffer, so if anyone else has any =
suggestions, they are free to add them to the RFC.

Some should be non-controversial, others a bit more.
If such, they might warrant their own dedicated RFC, or be dropped from =
the proposal altogether.

Best regards,

Gina P. Banyard