Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106079
MIME-Version: 1.0
References: <c-17aa9-jxbttytv-fj6p6s=1xtnjis@2.gethop.com> <6D1026FF-ECF1-4604-91A8-D290D37CC238@cschneid.com>
 <F6D115B8-0808-4EA6-B031-4CE61F3C5704@gmail.com> <CAG9XoMTJKFFF2hrxgjBy3_A+8MA6mbEg1_1o957fY6bP29G4Cw@mail.gmail.com>
 <F5FDFABD-2508-4D26-AE73-8829A068CA8F@cschneid.com> <CAG9XoMTb+g6g5gSFbvASeEcVj5N4crxgE1Exo120hJZLXRtwKQ@mail.gmail.com>
 <E86347D1-E6BA-4B5E-AB00-DD3C17F05B25@gmail.com> <CAG9XoMRBBB34gHqvnYTpzUgLvW=+V649AadPEhbDgAbLw+_c1Q@mail.gmail.com>
In-Reply-To: <CAG9XoMRBBB34gHqvnYTpzUgLvW=+V649AadPEhbDgAbLw+_c1Q@mail.gmail.com>
Date: Wed, 26 Jun 2019 22:57:57 +0200
Message-ID: <CANZOY=CbDQtcQ6azXwYTuJbk_-Fwpv=vvL1TS6T40krtm7Vm-w@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006d641c058c404dce"
Subject: Re: [PHP-DEV] [RFC] Strict operators directive
From: arnold.adaniels.nl@gmail.com (Arnold Daniels)

--0000000000006d641c058c404dce
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 26, 2019 at 1:46 PM Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> > * in some strict mode, reserve `<`, `=3D=3D` etc. for numeric compariso=
n, and
> throw a TypeError one of the operand is not numeric;
>
> > * If we deem it worth, define a new operators for string comparison.
> (Although I=E2=80=99m not really sure it is worth: we have `strcmp()` and=
 `=3D=3D=3D` for
> byte-to-byte comparison, and the Collator class for alphabetical sorting
> that actually works in languages not restricted to unaccented latin
> characters.)
>
> It's true that string comparison (sorting) is a much harder problem that
> cannot be solved without additional knowledge of the encoding of the
> string; so I agree that it might be better to just throw a TypeError when
> comparing strings, and leave the user with an operator that only works on
> numbers, and explicitly use dedicated functions when comparing strings.
>
> This makes sense for "<", "<=3D", ">", ">=3D", but what about "=3D=3D" an=
d "!=3D"?
>
> Currently, "11" =3D=3D "11.0"; what would this yield under the new propos=
al?
>
> - leave it as is: return true in this case =3D> contradicts the whole pur=
pose
> of the new proposal
> - throw a TypeError when performing the above comparison =3D> not accepta=
ble
> either I guess; every language allows =3D=3D and !=3D on strings, forcing=
 to use
> strict comparison operators is a bit weird here.
> - change the semantics to return false when both operands are strings, an=
d
> don't match =3D> not acceptable to you as you cannot know what a line of =
code
> does without checking the header
>
> What would you suggest here?
>
> Ben
>

PHP considers a string as a simple byte array. I want to stress that any
discussion about character sets or collations is beyond the scope of this
RFC.

The directive only affects the result of comparing two numeric strings and
non-numeric strings. As such, the RFC assumes the current result of
comparing non-numeric strings to be 100% correct. To those who disagree
with this assumption; please create a separate RFC to discuss this topic
and do not take it into consideration in regards to the strict_operators
RFC.
---

The RFC is modeled after `strict_types`, so to quote part of its
motivation  "... this RFC proposes a fourth approach: per-file strict or
weak type-checking. This has the following advantages: People can choose
the type checking model that suits them best, which means this approach
should hopefully placate both the strict and weak type checking camps. ..."

Take under consideration that the use of `strict_operators` is optional.
Those who are inclined to use it consider the current behavior of implicit
type casting to be problematic. As such, I imagine that this group does not
(want to) use code that exploits this behavior. Those who do not find the
current behavior problematic will typically not use the directive and thus
are unaffected by it. Disallowing all relational operators for strings is
too radical and primarily caters towards those who aren't inclined to use
the directive in the first place. In short; it's a compromise that makes
nobody happy.

The RFC will take the following stance; The directive is catering towards
those that find implicit casting by relational operators on two operands of
the same type, purely based on the value of those operands, very
undesirable. For the audience that's inclined to use the directive, any
issues that come from copy/pasting code that exploits this behavior are
considered acceptable and should be solved.
---

I've added two discussion points to the RFC based on the discussed concerns=
.

Arnold

--0000000000006d641c058c404dce--