This is the discussion page for operators.
I think this feature is too weak to be included. Here are some reasons why I think that:
==operator to one class and then comparing an instance
xof that class to a value
yof another type means that the result can easily differ depending on whether the programmer writes
x == yor
y == x. (If y has an operator
==too then its operator will be preferred in the latter case.) The most the author of the
==operator can do about this is to add types to the operator’s signature so that strict mode catches the bug or the program fails predictably at run-time.
Including operators as currently proposed would probably give us a headache if we wish to introduce a more powerful feature (probably based on some sort of ad-hoc overloading) in the future.
(I propose that we introduce generic functions instead, but even if that proposal is not accepted I still propose that we remove operators.)
— Lars T Hansen 2007/08/09 13:49
Are operators inherited?
The draft spec states that a static property on a base class cannot be referenced through instances of its derived classes, so in a real sense a class does not “have” a static operator function inherited from a base class.
Proposed resolution: Operators are not inherited, they must be defined on the actual concrete classes in each instance.
Whether they are inherited or not, do we wish to allow for a way of referencing operators defined in a superclass or in a particular class?
Proposed resolution: The reserved namespace
operator will be available for invoking an operator function on a given class, eg C.operator::+(1,2).
operator namespace necessary? See Syntax for field names in class definitions at the bottom of syntax for type expressions (it needs a new home). Is there a proposal or spec already for declaring and using property names that are not lexical identifiers? If so, why wouldn’t it suffice to name operator static methods?
One reason we’ve discussed, which led to exposing the unquoted operator lexemes as method names: so that the lexer can sort things out up front. But a new predefined namespace is not necessary for that.
In contrast, the intrinsic namespace proposal was created in part to make global default operator functions, which operate on arguments of any type, available without polluting the global public namespace.
— Brendan Eich 2006/04/27 09:27
operator namespace seems to me a good idea on reflection. But it’s not reflected in the proposal yet, or the referenced part of the spec.
— Brendan Eich 2007/01/29 11:32
If operators are inherited, can they be overridden?
Proposed resolution: Since they are proposed not to be inherited, this point is moot.