Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106080
MIME-Version: 1.0
References: <c-17aa9-jxbttytv-fj6p6s=1xtnjis@2.gethop.com> <2c0a414b-859d-3c25-d92a-048c1b8b259f@xs4all.nl>
In-Reply-To: <2c0a414b-859d-3c25-d92a-048c1b8b259f@xs4all.nl>
Date: Wed, 26 Jun 2019 23:22:45 +0200
Message-ID: <CANZOY=BpDdubFikmk48p4AbhUhSwFi1jx3oi8VJ+UuAZjTg-gA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001f30b8058c40a6dd"
Subject: Re: [PHP-DEV] [RFC] Strict operators directive
From: arnold.adaniels.nl@gmail.com (Arnold Daniels)

--0000000000001f30b8058c40a6dd
Content-Type: text/plain; charset="UTF-8"

Hi Dik,

Thanks for taking the time to review this RFC.

On Wed, Jun 26, 2019 at 10:44 PM Dik Takken <d.takken@xs4all.nl> wrote:

> Hello,
>
> Thanks a lot for your work on this RFC, it looks like a nice way to
> allow the language to gradually move forward.
>
> As pointed out by others, the ==, ===, != and !== operators are a bit
> problematic. A possible solution could be to leave them out of the RFC.
> The reason to do so is that the choice between strict or non-strict
> comparison is already possible by choosing the appropriate operator. In
> my view, explicitly using == in stead of === is either intentional or a
> bug. If it is intentional, the author consciously chose to be
> non-strict. The strictness declaration would then only affect operators
> for which no strict variant exists or where the operator is implicit
> (switch statement).


I would argue the following; The explicit use of the strict_operator is
intentional, meaning that the author consciously chose to be strict and
does not expect some operators to still be non-strict. The issues pointed
out, apply to all comparison operators. Ignoring == and != in the RFC
creates an inconsistency, while not properly addressing those concerns.


> As for changing the behavior of in_array() and friends: I would love the
> idea of not having to use the strict argument everywhere anymore.
> However, changing behavior of functions that are not in the same file
> that has the strictness declaration seems inconsistent. The scope of the
> declaration would not be well defined anymore. There may be other means
> to fix this annoyance, like introducing a strict variant of in_array().
>

:+1:


> Regarding the switch statement: While it is not an operator, one could
> argue that it is a case of implicit use of an operator.
>

I agree. Internally it's defined as an operator even. Still, I'll put this
up as a secondary vote.


> Regards,
> Dik Takken
>

--0000000000001f30b8058c40a6dd--