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]

Reply via email to