Re: [RFC] Strict operators directive
| From: | Claude Pache | Date: | Wed, 26 Jun 2019 10:39:09 +0000 |
| Subject: | Re: [RFC] Strict operators directive | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-106070@lists.php.net to get a copy of this message | ||
> Le 26 juin 2019 à 11:36, Benjamin Morel <benjamin.morel@gmail.com> a écrit :
>
>> (...) 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.
>
> 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.
>
> I'm starting to believe that a joint effort to fork PHP if the only way out
> :(
>
> Ben
It would be something “different”, but not necessarily “better”.
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="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 == 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 ==.
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 <, == 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’m not really sure
it is worth: we have strcmp() and === for byte-to-byte comparison, and the
Collator class for alphabetical sorting that actually works in languages not restricted to
unaccented latin characters.)
—Claude