Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106073
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>
In-Reply-To: <E86347D1-E6BA-4B5E-AB00-DD3C17F05B25@gmail.com>
Date: Wed, 26 Jun 2019 13:46:03 +0200
Message-ID: <CAG9XoMRBBB34gHqvnYTpzUgLvW=+V649AadPEhbDgAbLw+_c1Q@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ca7cb4058c38978f"
Subject: Re: [PHP-DEV] [RFC] Strict operators directive
From: benjamin.morel@gmail.com (Benjamin Morel)

--000000000000ca7cb4058c38978f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> * in some strict mode, reserve `<`, `=3D=3D` etc. for numeric comparison,=
 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" and =
"!=3D"?

Currently, "11" =3D=3D "11.0"; what would this yield under the new proposal=
?

- leave it as is: return true in this case =3D> contradicts the whole purpo=
se
of the new proposal
- throw a TypeError when performing the above comparison =3D> not acceptabl=
e
either I guess; every language allows =3D=3D and !=3D on strings, forcing t=
o use
strict comparison operators is a bit weird here.
- change the semantics to return false when both operands are strings, and
don't match =3D> not acceptable to you as you cannot know what a line of co=
de
does without checking the header

What would you suggest here?

Ben

--000000000000ca7cb4058c38978f--