> * 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
