Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116737
Message-ID: <5ca1c05f-273e-d1f9-5be0-32eee68a6fe1@gmail.com>
Date: Wed, 29 Dec 2021 17:23:24 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.1
Content-Language: en-GB
To: internals@lists.php.net
References: <CABEW5qdH4w3JJpvZP4pD4R2tTvAFLiPZ_UNBnwA_38cZ4Mf8og@mail.gmail.com>
 <CANS-=peiUx+vYsV-mzEjKQ=W=w2YGrpcDU-1Woj5HOAmQJBFLg@mail.gmail.com>
In-Reply-To: <CANS-=peiUx+vYsV-mzEjKQ=W=w2YGrpcDU-1Woj5HOAmQJBFLg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int
 when using them as array-key
From: rowan.collins@gmail.com (Rowan Tommins)

On 29/12/2021 16:58, Lynn wrote:
> While I'd love for this inconsistency to go away, I also know that this is
> most likely such a big change that it causes months of work and broken code
> because it relies on this behavior. It wouldn't surprise me if this
> singular change would cause more work than all previous BC breaks combined.


I was about to say the same thing - this is one of those ingrained 
behaviours that is very hard to analyse use of without running the code, 
so only someone with an extraordinarily good test suite would detect 
that their code was affected before it went live.

Like a lot of PHP's type juggling features, it is surprising in a pure 
data crunching context, but extremely reasonable in PHP's original and 
still very popular context of processing input from web forms. For 
instance, a list of products fetched from a database will likely have 
indexes which are integers, but a value from $_GET or $_POST will always 
be a string. It's therefore quite helpful that $products[42] and 
$products['42'] refer to the same thing, so that you can write 
$products[$_GET['id']] rather than $products[(int)$_GET['id']].

Would this feature be included in a language designed with knowledge of 
how PHP is used today? Possibly not, but we have no time machine to 
change our minds now.

One vaguely plausible (but not easy to implement) way forward is to have 
new array-like types, where keys and values can be constrained in 
different ways. Then it could obey the local scalar type passing setting 
("strict_types") to allow combinations like this:

declare(strict_types=0);
$stringKeyedArray = new dict<string,mixed>;
$stringKeyedArray['42'] = true; // key kept as '42'
$stringKeyedArray[42] = true; // actually sets key '42'
$intKeyedArray = new dict<int,mixed>;
$intKeyedArray[42] = true; // key kept as 42
$intKeyedArray['42'] = true; // actually sets key 42

declare(strict_types=1);
$stringKeyedArray = new dict<string,mixed>;
$stringKeyedArray['42'] = true; // key kept as '42'
$stringKeyedArray[42] = true; // TypeError
$intKeyedArray = new dict<int,mixed>;
$intKeyedArray[42] = true; // key kept as 42
$intKeyedArray['42'] = true; // TypeError

Regards,

-- 
Rowan Tommins
[IMSoP]