Re: [RFC] Strict operators directive

From: 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

« previous php.internals (#106070) next »