Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127945
Message-ID: <3d3dfc56-3958-4997-9172-118d0e89950a@gmail.com>
Date: Mon, 7 Jul 2025 19:03:39 +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>
 <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
 <1yx0GE3X9ysln_bTni-MXXWHDPtPXcmPKaO6bySOiGjkjyFCMCB_wKz67XuEt_sifpZC63kkzreaNt4Trlrpir4MKRCgfkBV0X00cvQq1dA=@gpb.moe>
Content-Language: en-US
In-Reply-To: <1yx0GE3X9ysln_bTni-MXXWHDPtPXcmPKaO6bySOiGjkjyFCMCB_wKz67XuEt_sifpZC63kkzreaNt4Trlrpir4MKRCgfkBV0X00cvQq1dA=@gpb.moe>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
From: dossche.niels@gmail.com (Niels Dossche)

On 07/07/2025 17:48, Gina P. Banyard wrote:
> On Friday, 4 July 2025 at 08:04, Niels Dossche <dossche.niels@gmail.com> wrote:
> 
>> 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 have added the deprecations messages for my own proposals,

Thanks!

> 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 should be able to improve it at any point.

True, and I have voted against things before due to implementation details.

> 
> 
>> 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 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.
> 
> 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 bool would neither if my other RFC is approved.
> Moreover, a type declaration of int|string accepted Stringable objects, however array offsets do not accept objects at all.

I'll clarify:
You're allowed to do $array[null], $array[3.14], etc... and the key will coerce.
I expect array_key_exists() to behave the same way as keys on array accesses do.

>> * 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.
> 
> As replied to Ilija, and as Tim already mentioned, the workaround do NOT behave the same way as passing the function directly.

Yeah, I misunderstood this.

Kind regards
Niels