On Wed, Jun 26, 2019 at 1:46 PM Benjamin Morel <benjamin.mo...@gmail.com> wrote:
> > * 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.) > > 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 "<", "<=", ">", ">=", but what about "==" and "!="? > > Currently, "11" == "11.0"; what would this yield under the new proposal? > > - leave it as is: return true in this case => contradicts the whole purpose > of the new proposal > - throw a TypeError when performing the above comparison => not acceptable > either I guess; every language allows == and != on strings, forcing to use > strict comparison operators is a bit weird here. > - change the semantics to return false when both operands are strings, and > don't match => 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
