Array comparison with strict operators
| From: | Arnold Daniels | Date: | Tue, 21 Apr 2020 15:06:32 +0000 |
| Subject: | Array comparison with strict operators | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-109755@lists.php.net to get a copy of this message | ||
Hi all,
In preparation for restarting the discussion on the strict operators RFC, I'm critically
looking at cases where no TypeError is thrown, but the behavior changes instead.
Comparing two arrays using
== is particularly fuzzy at the moment. An array in PHP is
actually an ordered map. Using == will compare the operands as unordered maps. This is
a useful feature, but maybe not generally expected. In addition == applies recursively,
so type juggling is done on all elements of the array. Objects within the array are compared on
equality rather than identity.
It's not possible to compare arrays as unordered maps without type juggling and by object
identity. Similarly, it's not possible to compare arrays as ordered maps but with type juggling
and by object equality. For example;
['x' => 1.0, 'y' => 2.0] == ['y' => 2.0, 'x' =>
1.0]; // true
['x' => 1.0, 'y' => 2.0] === ['y' => 2.0, 'x' =>
1.0]; // false because of key order
['x' => 1.0, 'y' => 2.0] == ['x' => 1, 'y' =>
2]; // true
['x' => 1.0, 'y' => 2.0] === ['x' => 1, 'y' =>
2]; // false because no type juggling
The RFC touches this subject but doesn't properly solve it. The example above still applies
when using strict operators.
Additionally comparing a string to a number would always give a TypeError. Always returning
false when comparing operands of different types (like in other languages) would return
in too many cases where the behavior changes. The same could be said for elements of an array.
It's not uncommon to compare numeric string to numbers (int/float) and preferably behavior
shouldn't change in that case. To achieve this it's possible to throw an error if the
types of two elements with the same key don't match. But I believe many would consider this
unexpected and unwanted behavior, especially in combination with the first issue discussed.
The same issues also apply (to some extend) to objects. The behavior of two objects with numeric
string and a number would change with strict operators.
Allowing comparison between a numeric string and a number would solve some of the issues, but
undermine the concept of the RFC since it would mean throwing an error based on the value, rather
than just the type. Additionally, it wouldn't solve the issue completely.
Any thoughts on this are appreciated.
Thanks,
Arnold
[Arnold Daniels - Chat @
Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=h4jnw) [h4jnw]