Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106070
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAG9XoMTb+g6g5gSFbvASeEcVj5N4crxgE1Exo120hJZLXRtwKQ@mail.gmail.com>
Date: Wed, 26 Jun 2019 12:39:09 +0200
Cc: Christian Schneider <cschneid@cschneid.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E86347D1-E6BA-4B5E-AB00-DD3C17F05B25@gmail.com>
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>
To: Benjamin Morel <benjamin.morel@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Strict operators directive
From: claude.pache@gmail.com (Claude Pache)



> Le 26 juin 2019 =C3=A0 11:36, Benjamin Morel =
<benjamin.morel@gmail.com> a =C3=A9crit :
>=20
>> (...) could be the case depending on a declaration somewhere else in =
the
> source code.
>> That's the confusion Claude and I were talking about: You cannot be =
sure
> what a very simple line of code does.
>=20
> Oh, I see. You mean that only replacing some of the current results =
with
> TypeErrors would be acceptable; returning a different value would not.
> This makes a lot of sense, but once again prevents the language from =
slowly
> moving towards something different (and better), leaving it stuck in =
its
> legacy forever.
>=20
> I'm starting to believe that a joint effort to fork PHP if the only =
way out
> :(
>=20
> Ben


It would be something =E2=80=9Cdifferent=E2=80=9D, but not necessarily =
=E2=80=9Cbetter=E2=80=9D.

Programmers may intentionally rely on the current semantics when =
comparing numeric strings, e.g. in the following cases:
* values that are grabbed from a database using a driver that returns =
only strings (or nulls);
* values that are read from $_POST and that ultimately stems from some =
HTML <input type=3D"number"> element.

-------

It was certainly a fundamental design error to have both implicit type =
conversion and operators that did different things based on the type of =
their operands. That leads to the infamous `"1" + 1 =3D=3D 11` problem =
in JavaScript, or the the "3" < "24" problem in PHP. That could have =
been avoided in two ways:
* either by forbidding implicit conversion;
* or by using different operators for different types (as does Perl).

Now, returning to the case of the comparison operators like `<` or `=3D=3D=
`. Instead of killing implicit conversion and redefining the meaning of =
those operators in cases that are *not* just edge case, it may be =
preferable to use the other approach:

* 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.)

=E2=80=94Claude