[RFC][DISCUSSION] Strict operators directive

Hey Arnold,

Perhaps it makes sense for <=> to still operate with other types, as long
as they are uniform? Specifically:

• error: 1 <=> "1"
• ok: "a" <=> "b"
• ok: true <=> false

Using ==, !=, and <=> with string operands can lead to unexpected
results because the operation differs when both operands are numeric
strings. Instead strcmp or Collator::compare() should be used. See
https://wiki.php.net/rfc/strict_operators#numeric_string_comparison

Boolean operands could be allowed but that has limited use. Only allowing
int or float is much clearer.

Similar for sorting: I use <=> to differentiate multi-dimensional arrays:
perhaps it should error if the array structure differs?

Some functionality concerning comparing objects and arrays is lost with
strict_operators unfortunately. The RFC reduces complexity by throwing an
error purely based on the type of operands and not based on the value of
the operands. Alternatives where == and != are supported for all types,
are as complex as the comparison rules without strict_operators and/or
result in cases where the outcome of an operation is changed based on the
directive.

The rest of the proposal makes a lot of sense to me.

Thanks.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels <
arnold.adaniels.nl@gmail.com> wrote:

Hi all,

I'd like to start the discussion of the "Strict operators directive" RFC
version 1.5. This RFC proposes a new directive strict_operators, which
limits the type juggling done by operators to avoid unexpected results.

https://wiki.php.net/rfc/strict_operators

There are some significant changes from the previous version.
strict_operators no longer has cases where it changes the outcome of an
operation. To achieve this the following changes are made to the RFC

• All comparison operators, besides === and !==, only accept int
  and float operands. For any other type a TypeError is thrown. This
  includes == and !=.
• The switch statement is not affected.

For frequently asked questions please see
https://wiki.php.net/rfc/strict_operators/faq.

Arnold Daniels - Chat @ Spike
[l1bam]

On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels <
arnold.adaniels.nl@gmail.com> wrote:

Hi all,

I'd like to start the discussion of the "Strict operators directive" RFC
version 1.5. This RFC proposes a new directive strict_operators, which
limits the type juggling done by operators to avoid unexpected results.

https://wiki.php.net/rfc/strict_operators

There are some significant changes from the previous version.
strict_operators no longer has cases where it changes the outcome of an
operation. To achieve this the following changes are made to the RFC

• All comparison operators, besides === and !==, only accept int
  and float operands. For any other type a TypeError is thrown. This
  includes == and !=.

what about DateTime and other objects overwriting comparison operators?
(GMP, ...) How would this proposal affect future proposals that expose
comparisons to userland (see for example the operator overloading RFC).

Custom compare handlers of objects (like DateTime and GMP) will be applied
regardless of strict_operators. The ZEND_COMPARE_OBJECTS_FALLBACK macro
will throw a TypeError if two objects are compared with different handlers.

Converting an int to GMP is a widening primitive conversion and therefore
allowed. I will modify the GMP compare handler as part of this RFC to throw
a TypeError if the other operand isn't an 'int' or GMP object.

Future proposals for userland custom comparisons should preferably adhere
to the stricter rules for type conversion this RFC suggests, regardless of
the strict_operators directive. In that case, it shouldn't be an issue to
allow such objects as operands of overloaded operators.

• The switch statement is not affected.

For frequently asked questions please see
https://wiki.php.net/rfc/strict_operators/faq.

Honestly PHP comparisons are already complex enough, introducing a second
set of rules that are just as complex seems like a risky proposal to me.

PHP comparisons are currently very complex. This RFC attempts to
reduce/eliminate that complexity. Can you explain why the rules are still
too complex and perhaps how they can be simplified more?

Arnold Daniels - Chat @ Spike
[l1bam]