On Mon, Jul 6, 2020 at 6:33 PM Benjamin Eberlei <kont...@beberlei.de> wrote:
> > > On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels < > arnold.adaniels...@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]( >> https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam) >> [l1bam] > >
