Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127922
Message-ID: <0b5a9e16-9b1e-400f-a092-eb5937a8c823@bastelstu.be>
Date: Sun, 6 Jul 2025 19:16:16 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
To: Bob Weinand <bobwei9@hotmail.com>, internals@lists.php.net
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
 <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
 <b56286ec-d1ed-4057-b813-0155d6ca1208@bastelstu.be>
 <AM8P250MB0170F9A04CC7DCDE0D8B731EE24CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Content-Language: en-US
In-Reply-To: <AM8P250MB0170F9A04CC7DCDE0D8B731EE24CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.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/6/25 19:00, Bob Weinand wrote:
> Let me disagree with this. Yes, a deprecation in *itself* doesn't break
> running code. However it is both a) an annoyance (you want to get rid of
> deprecations) and b) a promise that it will be eventually broken.

Yes, I understand that a deprecation *usually* leads to a removal.

Nevertheless I found it important to point out that the deprecation 
itself is not a breaking change, since it is a common theme that folks 
incorrectly claim that "PHP X.Y broke my code", when it's just some 
deprecation messages being emitted. The deprecation allows you to fix 
the issue at hand at a pace you are comfortable with. As an example, if 
the code in question is in the process of being replaced anyways, then 
you don't need to do anything.

 From my personal anecdata: I'm fixing deprecations right away and the 
only painful one I'm remembering in the recent years is 
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg. For this 
iteration, I'm likewise expecting most of them to be easily handled with 
the existing tooling (IDEs, Code formatters, …).

Also, even for PHP 8.4, where the proposed deprecation of `uniqid()` 
(and others) specifically said that there are *no plans for removal* 
(https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_uniqid), folks 
considered the deprecation warning alone to be an inacceptable breaking 
change.

> And there's not always a point in breaking real code for the sake of
> "this might be potentially confusing".

Yes, the amount of possible confusion certainly needs to be weighted 
against the amount of usage. As a rule of thumb, I'd claim that the more 
commonly a specific syntax is used, the less confusing it becomes, since 
there are more references in the wild for folks to come across.

Best regards
Tim Düsterhus