This project is read-only.

Possibility to provide operators in interface

Topics: C# Language Design
Oct 28, 2014 at 9:33 AM

I'm totally missing the feature that I can create operator declarations on interfaces. I currently have to declare the interface on the abstract base class but not on the interface.

Since the developers of our framework are mostly physicists and are not realizing what's necessary to have clear code they always modify the abstract base class, since due to the missing feature I cannot pass the interface as a parameter but the abstract class itself. This hinders me to make a clear implementation.

Since I have read that this feature has been requestes many times, is there a timeline when this feature will be in?

Nov 10, 2014 at 1:55 AM
I can see how that would be useful. For instance, there could be a INumeric interface implemented by the built-in primitive types (int, double, etc) which would declare the operators for addition, subtraction, multiplication, etc (*). This would make it much easier to write generic code that works on any numeric type.

However, there are a few problems with this idea. Currently, overloaded operators are static methods, but interfaces can only define instance methods. So a prerequisite for this feature would be to allow operators to be instance methods; that would be a pretty major change, with dangerous side effects. For instance, it would enable virtual operators. While this could be useful, it would be contrary to the current situation where operators are never polymorphic.

Let's assume that we settle on a syntax like this:
public MyType operator+(MyType other) { return Add(this, other); }
This would serve the same purpose as this:
public static MyType operator+(MyType x, MyType y) { return Add(x, y); }
(Obviously, we can't allow the static version if the instance version exists, and vice versa, because it would cause an ambiguity)

But now we have a problem: depending on whether the operator is an instance or static operator, it will be virtual or not. This would be very confusing, especially since there is no easy way for the developer to see if it is an instance or static operator.

Also, what about null checking? A static operator can accept a null operand, but calling an instance operator on a null reference will cause a NullReferenceException.

(*) even without operators declared in interfaces, I still like the idea of an INumeric interface; but it would have to declare methods rather than operators
Nov 10, 2014 at 6:53 PM
Edited Nov 10, 2014 at 6:55 PM
Are there factors that preclude having operators be usable on interfaces even in cases where one of the operands is a class? Obviously in the absence of a means of "prioritizing" overloads, situations where no single overload was clearly superior to all others would be more common with interfaces than with classes, but is there anything structural in the Framework which would prevent a language from allowing the use of operators with interface types? Obviously a language would need to make sure that existing bindings are not affected by the new interface bindings, but if if there were a means of prioritizing overloads, that could easily be accomplished.