Re: [RFC] Deprecations for PHP 8.5

From: Date: Mon, 07 Jul 2025 19:49:19 +0000
Subject: Re: [RFC] Deprecations for PHP 8.5
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-127951@lists.php.net to get a copy of this message
On 07/07/2025 21:19, Theodore Brown wrote:
> On Mon, July 7, 2025 at 11:03 Niels Dossche wrote:
>> 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.
> 
> I'm confused what you mean as well. The deprecation is for both array offsets and when
> calling array_key_exists().
> So $array[null] should output a deprecation just like the function, and there isn't any
> inconsistency.

Okay now I understand. I misread the description and missed the word "and".

However, I still need some clarifications:

From the RFC:
> Notably an offset of null is type juggled to the empty string "" rather than 0,
> contrasting with how values of type bool, float, and resources are cast to int.

Why is this wrong? Why must it get cast to 0?

From the RFC:
> Which is even more surprising that the other operators that accept both string and int are
> bitwise operators and they throw a type error when attempting to use null with a value of type
> string.

I tried understanding this sentence multiple times but I just don't understand what it's
saying.
Even presuming that the first "that" should maybe be "than", I still don't
understand it.

Kind regards
Niels


Thread (73 messages)

« previous php.internals (#127951) next »