[Proposal][Operator Overloading Enhancement]

[redradist]

Issue

Consider the following code:

using System;

class Being
{
    protected int i = 0;
    
    public static Being operator+(Being be, int i)
    {
        be.i += i;
        return be;
    }

    public override string ToString()
    {
        return $"Being {{ i = {i}}}";
    }
}

class Human : Being
{
    public static Human operator+(Human hu, int i)
    {
        hu.i += (i + 2);
        return hu;
    }
    
    public override string ToString()
    {
        return $"Human {{ i = {i}}}";
    }
}

class Program
{
         
    static void Main(string[] args)
    {
        Human human = new Human();
        Console.WriteLine($"Before += human is {human}");
        human += 1;
        Console.WriteLine($"After += human is {human}");
        Being being = human;
        Console.WriteLine($"Before += being is {being}");
        being += 1;
        Console.WriteLine($"After += being is {being}");
    }
}

This seems inconsistent and not obvious.
Solution to it is obvious:

using System;
 
 class Being
 {
     protected int i = 0;
     
     public static Being operator+(Being being, int i)
     {
         return being.Add(i);
     }

     protected virtual Being Add(int i)
     {
         this.i += i;
         return this;
     }
     
     public override string ToString()
     {
         return $"Being {{ i = {i}}}";
     }
 }
 
 class Human : Being
 {
     public static Human operator+(Human human, int i)
     {
         return (Human) human.Add(i);
     }
     
     protected override Being Add(int i)
     {
         this.i += (i + 2);
         return this;
     }
     
     public override string ToString()
     {
         return $"Human {{ i = {i}}}";
     }
 }
 
 class Program
 {
          
     static void Main(string[] args)
     {
         Human human = new Human();
         Console.WriteLine($"Before += human is {human}");
         human += 1;
         Console.WriteLine($"After += human is {human}");
         Being being = human;
         Console.WriteLine($"Before += being is {being}");
         being += 1;
         Console.WriteLine($"After += being is {being}");
     }
 }

But it is error-prone to make helper virtual function every time. Compiler can generate it instead

Proposal

Consider adding virtual operator member function like in the following example:

using System;
 
 class Being
 {
     protected int i = 0;
     
     public [virtual] Being operator+(int i)
     {
         this.i += i;
         return this;
     }

    /* Below Generated code
     public static Being operator+(Being being, int i)
     {
         return being.Add(i);
     }

     public static Being operator+(int i, Being being)
     {
         return being.Add(i);
     }

     protected [virtual] Being Add(int i)
     {
         this.i += i;
         return this;
     }
     */

     public override string ToString()
     {
         return $"Being {{ i = {i}}}";
     }
 }
 
 class Human : Being
 {
     public [virtual|override] Human operator+(int i)
     {
         this.i += (i + 2);
         return this;
     }

    /* Below Generated code
     public static Human operator+(Human human, int i)
     {
         return human.Add(i);
     }

     public static Human operator+(int i, Human human)
     {
         return human.Add(i);
     }

     protected [virtual|override] Human Add(int i)
     {
         this.i += i;
         return this;
     }
     */

     public override string ToString()
     {
         return $"Human {{ i = {i}}}";
     }
 }
 
 class Program
 {
          
     static void Main(string[] args)
     {
         Human human = new Human();
         Console.WriteLine($"Before += human is {human}");
         human += 1;
         human = human + 1; // Operator is symmetric
         human = 1 + human; // Operator is symmetric
         Console.WriteLine($"After += human is {human}");
         Being being = human;
         Console.WriteLine($"Before += being is {being}");
         being += 1;
         being = being + 1; // Operator is symmetric
         being = 1 + being; // Operator is symmetric
         Console.WriteLine($"After += being is {being}");
     }
 }

For asymmetric operator behavior you should write something like this:

using System;
 
 class Being
 {
     protected int i = 0;
     
     public Being left operator+(int i)  // or loperator
     {
         this.i += (i + 5);
         return this;
     }
     
     public Being right operator+(int i)  // or roperator
     {
         this.i += (i + 2);
         return this;
     }
     
     public override string ToString()
     {
         return $"Being {{ i = {i}}}";
     }
 }
 
 class Human : Being
 {
     public Human operator+(int i)
     {
         this.i += (i + 2);
         return this;
     }
     
     public override string ToString()
     {
         return $"Human {{ i = {i}}}";
     }
 }
 
 class Program
 {
          
     static void Main(string[] args)
     {
         Human human = new Human();
         Console.WriteLine($"Before += human is {human}");
         human += 1;
         human = human + 1; // Operator is symmetric
         human = 1 + human; // Operator is symmetric
         Console.WriteLine($"After += human is {human}");

         Being being = human;
         Console.WriteLine($"Before += being is {being}");
         being += 1;
         being = being + 1; // Operator is symmetric
         being = 1 + being; // Operator is symmetric
         Console.WriteLine($"After += being is {being}");

         Being being2= new Being();
         Console.WriteLine($"Before += being2 is {being2}");
         being2+= 1;
         being2= being2+ 1; // Right Operator is symmetric
         being2= 1 + being2; // Left Operator is symmetric
         Console.WriteLine($"After += being2 is {being2}");
     }
 }

Under the hood it will work as follows as this first example by adding the helper function under hood

[YairHalberstadt]

There are a number of issues with this proposal:

1: Operators are static methods, and so cannot by definition be virtual. Making them instance methods would break them if they were ever called on a null instance. This would be a huge issue!

2. It was specifically decided that methods should be non-virtual by default for a whole host of reasons. You are now suggesting that not only should operators be virtual by default, they should also be overridden by default. This very much goes against the spirit of the language.

[svick]

My main issue with this proposal is that I don't see how doing this would be worth it. You're proposing adding a feature that will make writing one very specific, very rare pattern easier. I don't think making the language more complicate for that makes sense.

[redradist]

My main issue with this proposal is that I don't see how doing this would be worth it. You're proposing adding a feature that will make writing one very specific, very rare pattern easier. I don't think making the language more complicate for that makes sense.

It will make easier to extend the existing class without worrying that somebody will cast class to parent and will use wrong operator

[theunrepentantgeek]

In addition to the other issues already mentioned, this would break existing code.

[redradist]

There are a number of issues with this proposal:

1: Operators are static methods, and so cannot by definition be virtual. Making them instance methods would break them if they were ever called on a null instance. This would be a huge issue!

Why ? Just throw NullPointerException as for other instance methods. It is huge issue that somebody can cast my class to parent and ignore proper operator for instance

1. It was specifically decided that methods should be non-virtual by default for a whole host of reasons. You are now suggesting that not only should operators be virtual by default, they should also be overridden by default. This very much goes against the spirit of the language.

No !! I suggest old solution and new virtual instance operator methods to live together.
If you want use old style. If you want that class will be properly extended use a new solution

[redradist]

In addition to the other issues already mentioned, this would break existing code.

No it will not. I suggest to coexist old style and new style together (static operators and virtual instance operators)
Static operators are not a problem. They are just very limited

[CyrusNajmabadi]

It is huge issue that somebody can cast my class to parent and ignore proper operator for instance

Why is that a problem? This is how all static methods work. They're statically dispatched.

[YairHalberstadt]

In general operator overloading is only recommended when it's abundantly clear what the operators do. In practice this means outside mathsy code, operator overloading is probably best avoided. If the code won't work unless it's virtually dispatched, then it probably shouldn't be an operator to start off with.

[CyrusNajmabadi]

it's also super weird that you'd have an operator that behaved differently on a subclass. Sounds like a recipe for tons of confusion.

[Austin-bryan]

In addition to the other issues already mentioned, this would break existing code.

No it will not. I suggest to coexist old style and new style together (static operators and virtual instance operators)
Static operators are not a problem. They are just very limited

I must've misread your proposal but where did you mention that? Even if you do have the "two style" option somewhere, that is still bad and complicates code. Imagine one person marks the class in the new style, then another dev starts working on it, not realizing that things are implicitly virtual (bad idea) and implicitly overriden (even worse idea).

This would be completely inconsistent with the language, as well as requiring to rewrite how operators are written as they are static methods.

If you really want that behavior, then you make a method, it's that simple. That's what people've been doing for years now. Clearly the result you want is too complicated to be an operator.

Also, human += 1 makes absoletely no sense either. What am I adding? human.AddOperator(1) also makes no sense. Something like human.IncrementI(1) is far better in every way, and the way you should be programming. You seem to lack basic understanding of operators and C# conventions, that's your real issue.

[Richiban]

Guys, I think all @redradist is asking for is instance operators. Well, I say all--it is a huge change, but not a crazy one.

Why is it not possible to have a + b be the same as a.op_plus(b)? Obviously to avoid a breaking change the static operators would be searched first by the compiler and, if none is found, an instance method is tried. Operators are nothing but methods, after all.

Not saying I put my weight behind this proposal, just saying it's more reasonable than you're making out.

[HaloFour]

https://blogs.msdn.microsoft.com/ericlippert/2007/05/14/why-are-overloaded-operators-always-static-in-c/

[redradist]

Guys, I think all @redradist is asking for is instance operators. Well, I say all--it is a huge change, but not a crazy one.

Why is it not possible to have a + b be the same as a.op_plus(b)? Obviously to avoid a breaking change the static operators would be searched first by the compiler and, if none is found, an instance method is tried. Operators are nothing but methods, after all.

Not saying I put my weight behind this proposal, just saying it's more reasonable than you're making out.

Thank you @Richiban for support !!
I have updated proposal to show that it is possible to achieve without breaking changes.
For every instance operator methods just generate static operator method and helper instance method.
If static operator method and instance operator method defined in class it will cause ERROR
Otherwise old solution with static operator will be using or new solution will be using with instance method

[redradist]

https://blogs.msdn.microsoft.com/ericlippert/2007/05/14/why-are-overloaded-operators-always-static-in-c/

I have read this topic some time ago and also because of this article I have decided to write this proposal. According this article the main reason not to implement an instance operators was the following:
''
... If you define an operator+ that takes a C and an int, then c+2 is legal but 2+c is not, and that badly breaks our intuition about how the addition operator should behave. ...
''
But it could be solved like in Python with radd, by adding right or left contextual key word, or the roperator and loperator keywords

[HaloFour]

@redradist

But it could be solved like in Python with radd, by adding right or left contextual key word, or the roperator and loperator keywords

Yes, it could be solved, but that just adds more complexity. The designers of the language intentionally wanted to avoid those kinds of complexity and to keep operators simple. Operators don't exist to replace methods in the language and the language designers very intentionally wanted to avoid the character salad that C++ partially turned into.

As that blog post mentions it's fairly easy to recreate a virtual dispatch by having the static operators invoke instance methods. Given how easy it is to accomplish, and how rare such operators should be, it doesn't make much sense to encode it directly in the language. That would only encourage its use, and I think that you'd need to demonstrate good use cases where such operators are worth it. Your use cases are, if anything, examples of where you shouldn't be using operators.

[redradist]

@redradist

But it could be solved like in Python with radd, by adding right or left contextual key word, or the roperator and loperator keywords

Yes, it could be solved, but that just adds more complexity. The designers of the language intentionally wanted to avoid those kinds of complexity and to keep operators simple. Operators don't exist to replace methods in the language and the language designers very intentionally wanted to avoid the character salad that C++ partially turned into.

As that blog post mentions it's fairly easy to recreate a virtual dispatch by having the static operators invoke instance methods. Given how easy it is to accomplish, and how rare such operators should be, it doesn't make much sense to encode it directly in the language. That would only encourage its use, and I think that you'd need to demonstrate good use cases where such operators are worth it. Your use cases are, if anything, examples of where you shouldn't be using operators.

Example, no problems.
Lets imagine that I create Graphic Engine with my own Vector2, Vector3
For these class I need to implement the following operations: +-* and I want to extend my class in future
In this case for single class we need (2 (1 left + 1 right) + 1 (helper virtual function)) * 3 = 9
And I have to implement 9 methods instead of 3 and with more operators implemented by class I will need to implement more methods.
It is easy to make mistake or to forget to update something in this class properly. It is hard to maintain such code

I do not tell that adding contextual keywords is a good idea ...
For example instead of two keyword we can add one symmetric

[CyrusNajmabadi]

Lets imagine that I create Graphic Engine with my own Vector2, Vector3

This is not a good example . A graphics engine would not use classes here. They would use structs. So inheritance isn't interesting in this case.

However, for the sake of argument, say you did these as classes, and you used inheritance like so class Vector3 : Vector2 and you wanted operators. What about this scenario makes it so that you need virtual operators? Why is a normal static operator not sufficient here? AFAICT, the static operator will do the right thing for a Vector2 or a Vector3. If i multiple a Vector2 i get a Vector2. If i multiply a Vector3, i get a Vector3.

So, even with your example, i'm not seeing any need for virtual ops here (and that was being generous since you wouldn't actually do things this way in a real engine).

[HaloFour]

@redradist

Example, no problems.
Lets imagine that I create Graphic Engine with my own Vector2, Vector3

Such types already exist. Even if they didn't, you'd want to implement them as structs, not classes, especially in a graphics engine. There's no need for such types to be polymorphic or necessitate virtual dispatch. And lastly, even if you absolutely wanted to do this, you can. Write a static operator and have it call a virtual method. Yes, you're slightly inconvenienced, but how many times can that possibly come up? Certainly not enough to justify a language change, especially one that reverses a very intentional design choice.

[CyrusNajmabadi]

Note: @HaloFour are two different people. He's not an alt-account of mine. I swear!

[HaloFour]

I've always secretly wanted to be a llama. I wonder what llama bacon tastes like?

[Richiban]

@HaloFour wouldn't that be cannibalism?

…

On Wed, 12 Dec 2018, 20:09 HaloFour, ***@***.***> wrote: I've always secreted wanted to be a llama. I wonder what llama bacon tastes like? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/dotnet/csharplang/issues/2065#issuecomment-446726615>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAoyj3pzizUw2KKw2QDblmbisADQKUR1ks5u4WJ2gaJpZM4ZOUUo> .

[Austin-bryan]

There's really nothing gained from it. vectorA + vectorB is basically vectorA.Add(VectorB), so, as @HaloFour says, you're slightly inconvenienced in the not-common situtations.

There's more downsides than upsides to this, such as complexity and people abusing and misusing operators even more.

[orthoxerox]

Related: dotnet/roslyn#5909 (tldr: wontfix)