Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][DISCUSSION] Strict operators directive »

[RFC][DISCUSSION] Strict operators directive

php.internals

Arnold Daniels

6 years ago
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](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam) [l1bam]

Marco Pivetta

6 years ago
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 Similar for sorting: I use <=> to differentiate multi-dimensional arrays: perhaps it should error if the array structure differs? The rest of the proposal makes a lot of sense to me. 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:

Arnold Daniels

6 years ago
On Mon, Jul 6, 2020 at 6:22 PM Marco Pivetta <ocramius@gmail.com> wrote:
> 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.

Benjamin Eberlei

6 years ago
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). * 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.

Arnold Daniels

6 years ago
On Mon, Jul 6, 2020 at 6:33 PM Benjamin Eberlei <kontakt@beberlei.de> wrote:
> > > 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?