0

I recently got my hands on a copy of C# 7.0 in a Nutshell by Joseph and Ben Albahari. As I was browsing through the chapter on advanced C#, page 199 in particular where it begins covering operator overloading; I began wondering, has there been any official word on operator overloading similar to extension methods for at least primitive types? For example:

// Traditional Overload
public static MyType operator +(MyType, MyType);

// Traditional Extension Method
public static int Sum(this int, int[]);

// Possible Combination?
public static int operator +(this int, int, string);

In the example above, there is traditional overloading of the addition operator; this allows me to perform custom addition of properties of my type in order to supply a new value. Then there is the traditional extension method, in which we have the ability to extend types by adding methods we deem useful; similar to the example above, if I am frequently performing addition of all the values in an integer array to get their sum, then I could create a useful extension method to implement:

int sum = int.Sum(myArrayOfIntegers);

With all of this said, extended operator overloading could be useful, at least for primitives. For example:

public static int operator +(this int i, int x, string y) {
    // Perform parsing of the string and return the newly added value between x and y.
}

I could then perform arithmetic on multiple primitive types where useful and I wouldn't have to constantly attempt to parse data in my code. It's not that parsing data is difficult, but when you have to do the same thing hundreds of times (including calling a method to perform the parse and arithmetic), it can become tedious if anything.

I have done some searching and can't find anything relating to this topic since this post which was answered in 2008. Ten years is a long time, and I would hope the opinion from that post has changed since then.

I am sorry to report that we will not be doing this in the next release. We did take extension members very seriously in our plans, and spent a lot of effort trying to get them right, but in the end we couldn't get it smooth enough, and decided to give way to other interesting features.

This is still on our radar for future releases. What will help is if we get a good amount of compelling scenarios that can help drive the right design.

Still on our radar isn't very promising in my opinion.

Please only supply an answer if the resource is credible and current (or within the previous 2 years).

Community
  • 1
  • 1
Hazel へいぜる
  • 2,751
  • 1
  • 12
  • 44
  • How would you call that operator in an example? Anyway: why ask this here instead of Microsoft support? How should we know what MS plans on this? – MakePeaceGreatAgain Jun 29 '18 at 20:07
  • The language repo has a number of issues related to this and similar features (e.g. extension properties) which fall under the heading of "extension everything". One of the more recent issues is [here](https://github.com/dotnet/csharplang/issues/192). – Mike Zboray Jun 29 '18 at 20:45

1 Answers1

1

Yes it is. In C# 8, there will likely be "Extension Everything" as explained here on Github.

What "Extension Everything" Includes:

  • Extension static fields
  • Extension static Methods
  • Extension static properties
  • Extension properties
  • Extension indexers
  • Extension casting
  • Extension Operators

What it doesn't include:

  • Extension instance fields (at first)
  • Extension constructors (at first)
  • Extension events (at first)
  • Extension auto properties (not until they support extension instance fields)

The syntax will likely be something like this:

public extension class List2DExt<T> : List<List<T>> 
{
    // Extension static field
    private static int _flattenCount = 0;

    // Extension static property
    public static int FlattenCount => _flattenCount;

    // Extension static method
    public static int Get FlattenCount() => _flattenCount;

    // New syntax for extension methods
    public List<T> Flatten() { ... }

    // Extension indexers
    public List<List<T>> this[int[] indices] => ...;

    // Extension implicit operator
    public static implicit operator List<T>(List<List<T>> self) => self.Flatten();

    // Extension operator overload
    public static implicit List<List<T>> operator +(List<List<T>> left, List<List<T>> right) => left.Concat(right);
}

The reason why instance fields are not support at first is to do with how they'll have to keep track of the state of those fields, which I guess is tricky.

Community
  • 1
  • 1
AustinWBryan
  • 3,249
  • 3
  • 24
  • 42