PHP RFC: Strict operators directive

• Comparison operators == !=, >, >=, <, <= and <=> with non-numeric operands will throw a TypeError.
• Variable parsing in strings specified in double quotes and with heredoc, is also affected.
• Concatenation operation (using .) on null does not throw a TypeError, but will cast null to an empty string.

Making significant changes to the behavior of operators has severe consequences to backward compatibility. Additionally, there is a significant group of people who are in favor of the current method of type juggling. Following the rationale of PHP RFC: Scalar Type Declarations; an optional directive ensures backward compatibility and allows people to choose the type checking model that suits them best.

The main difference between the equal (==) and identical (===) operator, is that == doesn't perform type casting. By only disabling type casting with strict_operators, == would be similar to === for scalar types.

This RFC tries to avoid behaviorial changes based on the strict_operators directives.

The == and != operators compares two arrays as unsorted hashmaps. This is a useful feature. However, it's currently tied in with type juggling. Comparing the values of the array with type checking, similar to ===, would significatly change the behavior of an operation based on the strict_operators directive. Example; ['a' => null] == ['a' => 0] would result in true when the strict_operators is enabled and false otherwhise.

The == and != operators compares two objects by property. This is tied in with type juggling. Similar to arrays, comparing property values with === would change the behavior of the == operation.

Comparing two numeric strings using == and != will compare them as numbers. Disabling type juggling would change this behavior and make these operators the same as === and !=== in this case.

In many other languages, using ==, !=, <, >, <= and => with string operands performs an strcmp like operation. The <=> is even described as strcmp as operators. Why do these operators throw an exception with string operands when strict_operators is enabled?

It's common to use these operators when both operands are numeric strings. Having these statements return a different value based on the directive, could lead to issues, especially when source code is copy/pasted from an external codebase.

In case it concerns comparing text, it's better to use Collator::compare(). For non-collation related strings, like date strings, the strcmp function should be used.

Nikita Popov made the following argument:

Having $str1 < $str2 perform a strcmp() style comparison under strict_operators is surprising. I think that overall the use of lexicographical string comparisons is quite rare and should be performed using an explicit strcmp() call. More likely than not, writing $str1 < $str2 is a bug and should generate a TypeError. Of course, equality comparisons like $str1 == $str2 should still work, similar to the distinction you make for arrays.

The concatenation operator will cast integers, floats and (when __toString is defined) objects to a string. This is a common use case and operands are always typecasted to a string. Integers and floats always have a proper string representation.

Arithmetic operators won't cast strings to an integer or float, because not all strings can be properly represented as a number and a TypeError must be thrown based on the operand type only, not the value.

Both the concatenation operator and arithmetic operators throw a TypeError for arrays, resources, and objects. Casting these to a string or int/float doesn't give a proper representation of the value of the operand.

Using a boolean or null as operand for both concatenation and arithmetic operators also throws a TypeError. In most cases, the use of a boolean or null indicates an error as many functions return false or null in case of an error or when no result can be returned. This is different from the function returning an empty string or 0. ''%%strpos%%'' is a well-known example.

No, this will throw a TypeError. Users that use string operators need to explicitly typecast the string to an integer. If it concerns input data, for instance from $_POST, it's recommended to use the filter functions.

Arrays are sorted hashmaps in PHP but used as any type of collection like unsorted maps, lists, and sets. Only comparing as unsorted hashmap is supported using ==, while other cases require the use of functions like sort() and array_values().

Strict comparison of arrays as unsorted hashmaps currently isn't possible and requires sorting the array, prior to comparison.

With == unavailable when using strict_operators, sorting the array is the only option available.

ksort($array1);
ksort($array2);
 
$array1 === $array2;

Array functions might be added to compare arrays in different ways. But that's outside the scope of this RFC.

With the == operator, two object instances are equal if they have the same attributes and values, and are instances of the same class. Values are compared with ==, applying type juggling. Using === will check if the objects are the same instance.

When using strict_operators, == with objects will always throw a TypeError. With == unavailable, get_object_vars needs to be used.

get_class($object1) === get_class($object2) && get_object_vars($object1) === get_object_vars($object2);

Nikita Popov made the following argument:

String increment seems like a pretty niche use case, and I believe that many people find the overflow behavior quite surprising. I think it may be better to forbid string increment under strict_operators.

No. Only operators (including the case statement) in the source file that has declare(strict_operators=1) are affected. Functions defined elsewhere, including functions defined in extensions, are not affected.

Specifically sort() and in_array() will apply type jugging by default and require the use of the $sort_flags and $strict arguments to change the way the values are compared.

If both arrays must have the same keys in the same order, using < or > on two arrays can be useful. But, as shown in the examples, when this is not the case, these type of comparisons will yield unexpected results.

Throwing a TypeError only if the keys of the arrays don't match is not in line with this RFC. The behavior of an operator should not depend on the value of the operand, only on the type. Furthermore, a TypeError would be misplaced here, as some arrays would be accepted but others not, whereas a TypeError indicates no values of that type are accepted.

Internally the case of a switch is handled as a comparison operator. The issues with case are therefore similar to those of comparison operators. The audience that strict_operators caters to, may want to get rid of this behavior completely.

This is determined by a secondary vote.

No, not for operators.

If the secondary vote for strict comparison with switch is accepted, switch can give a different result.

No. Operators can still typecast under the given conditions. For instance, the concatenation (.) operator will cast an integer or float to a string, and boolean operators will cast any type of operand to a boolean.

Typecasting is also done in other places: if and while statements interpret expressions as boolean, and booleans and floats are cast to an integer when used as array keys.

This RFC is limited to the scope of operators.