Stop to automatically cast numeric-string to int when using them as array-key

[VincentLanglet]

Description

Currently we have

$a = ['01' => '01', '10' => '10'];

var_dump($a);
// (string) 01 => (string) 01
// (int) 10 => (string) 10
 
var_dump(array_flip($a));
// (string) 01 => (string) 01
// (int) 10 => (int) 10

var_dump(array_flip(array_flip($a)));
// (string) 01 => (string) 01
// (int) 10 => (int) 10

var_dump($a === array_flip(array_flip($a))); // false

Is there a reason to do this automatic cast from '10' to 10 when it's an array-key or wouldn't it be better to change this behavior for PHP 9 ?

To me it causes unexpected result like this one:

<?php

declare(strict_types=1);

function foo(string $string) {}

$array = ['01' => 5, '10' => 6];

$key = array_search(5, $array);
foo($key); // works

$key = array_search(6, $array);
foo($key); // crash

[iluuu1994]

Basically, this behavior is there to make [0 => 'foo']/['0' => 'foo'] and $array[0]/$array['0'] equivalent. Even if it's possible to persist the key types while keeping this behavior the same, any change in arrays will likely lead to countless subtle bugs in countless PHP code bases. There's also no good migration path to make users aware of this chance.

[VincentLanglet]

Basically, this behavior is there to make [0 => 'foo']/['0' => 'foo'] and $array[0]/$array['0'] equivalent.

I wasn't sure if it was intentional or if it was some weird things like 0 == "foo" prior to php8.
But I don't see useful case of $array[0]/$array['0'] equivalence.

Even if it's possible to persist the key types while keeping this behavior the same, any change in arrays will likely lead to countless subtle bugs in countless PHP code bases.

I would say that on the opposite that this behavior may currently be an easy way to introduce a bug in code base with array_flip changing the type or array_search not returning the expected type. I don't know how but this could be indeed interesting to see how big would be the impact of this change.

But even if it has some impacts, it should still be considered (a huge impact didn't prevent https://wiki.php.net/rfc/deprecate_dynamic_properties to be accepted).

To me, it's a follow-up of https://wiki.php.net/rfc/string_to_number_comparison and https://wiki.php.net/rfc/saner-numeric-strings.

There's also no good migration path to make users aware of this chance.

Given

$foo = ['0' => 1];
$foo['0'];
$foo[0];

$bar = [0 => 1];
$bar['0'];
$bar[0];

$foo == $bar; // true

What if $foo[0] trigger a deprecation:
"The key 0 was defined as a string ; please cast the key to string before accessing to the value or update the array key"
And $bar['0'] trigger a deprecation:
"The key '0' was defined as an int ; please cast the key to int before accessing to the value or update the array key"

This won't change anything but force people to update the code to

$foo = ['0' => 1];
$foo['0'];
$foo[(string) 0];

$bar = [0 => 1];
$bar[(int) '0'];
$bar[0];

which would work before and after the BC-break.

[cmb69]

In any way, changing this behavior would be a BC break, and so this should be backed by an RFC. Do you want to pursue the RFC process, @VincentLanglet?

[VincentLanglet]

Do you want to pursue the RFC process, @VincentLanglet?

Sure, but the introduction say that "If you don't have the skills to fully implement your RFC and no-one volunteers to code it, there is little chance your RFC will be successful.". And since I don't know C nor the php code base, It would require some help/volunteers.

And I thought issue was the new possible way to start an RFC. Should I email internals@lists.php.net instead ?

[cmb69]

Yes, please write to the internals mailing first, to get some initial feedback.

[KapitanOczywisty]

In JavaScript the Map object was introduced to make better key-value storage type without making BC to objects/arrays. Maybe in php this could also be the case.