Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110853
MIME-Version: 1.0
References: <c-17aa9-kcanr61p-tnd07y=1e5p5oh@2.gethop.com> <CAEPJduk5tZ+aViYM4BiEUSTcL3m3_=0Fs1Nc8R2LOAx3D0uh6A@mail.gmail.com>
In-Reply-To: <CAEPJduk5tZ+aViYM4BiEUSTcL3m3_=0Fs1Nc8R2LOAx3D0uh6A@mail.gmail.com>
Date: Mon, 6 Jul 2020 21:50:09 +0200
Message-ID: <CANZOY=DaF-6xeHAOnrJaMo41ezcUGeo4cBSDSUH8tsLuYHEAdw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004ae43c05a9cb2fec"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strict operators directive
From: arnold.adaniels.nl@gmail.com (Arnold Daniels)

--0000000000004ae43c05a9cb2fec
Content-Type: text/plain; charset="UTF-8"

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?


>> [Arnold Daniels - Chat @ Spike](
>> https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam)
>> [l1bam]
>
>

--0000000000004ae43c05a9cb2fec--