Extension operators

[gafter]

@dtsiniavskyi commented on Wed Sep 02 2015

Feature request, Language C#

I would love to see more extension like stuff in C#. In this case - extension operators. It would be great to have ability to implement operators outside theirs' class or in other projects. Something like:

public static class Extensions
{
    public static explicit operator ViewModel(Model b)
    {
        return new ViewModel { Foo = b.Foo.ToString() };
    }
}

so var viewModel = (ViewModel)model; code would be compilable like explicit operator was implemented inside ViewModel class.

---

@orthoxerox commented on Wed Sep 02 2015

+1 to that. string doesn't implement IReadOnlyList<char>, but an extension implicit cast would solve this issue for my purposes.

---

@dsaf commented on Wed Sep 02 2015

@orthoxerox I would raise an issue in https://github.com/dotnet/corefx/issues as well.

---

@orthoxerox commented on Wed Sep 02 2015

@dsaf, it's already there in coreclr, since System.String is in mscorlib: https://github.com/dotnet/coreclr/issues/542

---

@aluanhaddad commented on Fri Sep 18 2015

I very much like the idea of being able to write extension operators. This would be particularly useful for writing DSLs.

I think you should expand this proposal to include additional scenarios that demonstrate it's usefulness as the type casting example is not particularly strong. In particular, a generic extension operator.

I have one gripe with your proposed syntax. Specifically, I think that the this keyboard should be included and required for the sake of both consistency with existing extension forms and because it makes it clear that a type is being extended.

---

@rftobler commented on Sat Sep 19 2015

@aluanhaddad A few day ago I posted an example of using an extension operator for specializing generics that uses the this keyword: #5165. I think this example shows more of the power of operators as extension methods.

---

@alrz commented on Fri Apr 15 2016

This would allow to use types themselves as patterns which cause a conversion, e.g.

static class Extensions {
  public static explicit operator int?(string value) {
    return int.TryParse(value, out var result) ? result : null;
  }
}

// assuming a non-static `bool operator is(string, out string[])` for `Regex`
Regex regex = new Regex("...");
if(str is regex({int value})) {
  // ...
}

// translates to
if(regex.op_Match(str, out string[] captures)) {
  if(captures.Length == 1) {
    var temp = Extensions.op_Explicit(captures[0]);
    if (temp.HasValue) {
      var value = temp.GetValueOrDefault();
      // ...
    }
  }
}

Related: #10598, #5811

---

@gafter commented on Fri Apr 15 2016

@alrz

This would allow to use types themselves as patterns which cause a conversion, e.g.

No, it would not. Pattern-matching does not apply user-defined conversions. If it did, it would use the implicit ones only. Also, there is no "array pattern".

---

@alrz commented on Fri Apr 15 2016

@gafter I assumed the "array pattern" part. Anyway, so if we define it as implicit it does apply the conversion right? I'm asking because #10429 states that this would work only for constants.

---

@gafter commented on Fri Apr 15 2016

@alrz The only implicit user-defined conversion that would apply in any pattern-matching-like context is the conversion from the switch-expression of a switch-statement to a type that was switchable in C# 6: an enum, integral type, string, etc. We do not apply user-defined conversions in any other pattern-matching context.

---

@alrz commented on Fri Apr 15 2016

@gafter Is there a specific reason for this? Wouldn't it be more consistent if "it was allowed for all the types that is switchable in C#?". This statement is still true for C# 6.0 -- it applies the conversion to all the possible types for switch. Now that those types are relaxed to almost all types, why still stick to those restricted set of types (or none at all, in other contexts) when it comes to implicit conversion?

---

@gafter commented on Fri Apr 15 2016

@alrz Those are the types that can have constant expressions (except float, double, and decimal).

---

@alrz commented on Sat Apr 16 2016

@gafter Ok, if C# had support for extension is operators (I hope) that wouldn't be much of an issue,

static class StringExtensions {
  public static bool operator is(this string str, out int value) =>
    int.TryParse(str, out value);
}

if(str is regex({ string(int value) })) 
// and if we could omit known types in positional patterns
if(str is regex({ (int value) }))

if(regex.op_Match(str, out string[] captures)) {
  if(captures.Length == 1) {
    if(StringExtensions.op_Match(captures[0], out int value)) {
      // ...
    }
  }
}

That would be just perfect.

---

@gafter commented on Sat Apr 16 2016

Yes, obviously pattern-matching on something of type string should parse it as an int. </sarcasm>

---

@alrz commented on Sat Apr 16 2016

@gafter I am sure you saw my point though. I've defined an is operator for the type string that has an out parameter of type int so that you could bind it in a pattern to match against a string.

Basically T(..) pattern is only valid if the type T has an applicable is operator overload, right? So if we define something like bool is(string, out int) it would become a fallible positional pattern for the type string that could be bound to a variable of type int (or any other pattern that is compatible with the said type, in this case, int, e.g. a constant pattern) regardless of the implementation. Yes the example above does parse the input, I don't know what is wrong with that. I'm just saying that an extension operator is would enable us to do these kinds of utterly unreasonable evil dark magic. </sarcasm>

---

@gafter commented on Sat Apr 16 2016

@alrz I think you're imagining that pattern-matching does overload resolution on all of the possible operator is methods that it can find, based on the "expected" types of the patterns. It doesn't do that. If this is the pattern-matching operator for string, then parsing a string as an integer is what pattern-matching on a string (with one subpattern) would mean.

---

@alrz commented on Sat Apr 16 2016

@gafter So is overloads must have different number of out parameters regardless of their types? That is understandable because something like string(var value) would be ambiguous if it was overloaded. However, that would make some other use cases impossible to implement. What if I want to define two active patterns for string type like bool is(string, out int) for parsing case, and void is(string, out char[]) for extracting the char array? It would be nice if in these cases compiler require the explicit type (i.e. a type pattern) instead of var because the type obviously is not known to be omitted (something akin to "type ascription" to hint the compiler that what is the expected type in this particular case). This would be applied to out var as well; if you have multiple overloads which only differ in types then you cannot use out var and you must explicitly mention the expected type to select the desired overload.

---

@gafter commented on Sat Apr 16 2016

@alrz

What if I want to define two active patterns for string type like bool is(string, out int) for parsing case, and void is(string, out char[]) for extracting the char array?

You write a class that names each pattern you're trying to define, and you place the pattern-matching operation there. And then you use that name in the pattern so it is clear to the reader which of them is being used.

---

@alrz commented on Sun Apr 17 2016

@gafter So that would be something like this:

class Integer {
  public static bool operator is(string str, out int value) => int.TryParse(out value);
  // `Integer` vs `string` ------^
}

if(str is Integer(var value))

I suppose operator is would not be restricted to take the enclosing type as the first parameter, In contrast, conversion operators are restricted (CS0556).

Now, if I want to define it as an extension operator for the type int,

static class IntegerExtensions {
  public static bool operator is(this string str, out int value) => ... ;
}

It would not be clear that which type we are targeting. GetValues method also had this issue:

static class IntegerExtensions {
  public static bool GetValues(this string str, out int value) => ... ;
}

This is still an extension on type string and not int.

I think this needs something like #6136 to be clear about the intended target type.

extension Int32 {
   public static bool operator is(string str, out int value) => ... ;
}

I'm not aware of any plans for supporting extension is operators, though. But I do believe this will be really useful when you want to use positional patterns on types that don't already provide an operator is like expression trees (#10153 comment).

[MovGP0]

in the first example, I'd add a this keyword for the sake of consistency of extension methods:

public static class ModelExtensions
{
    public static explicit operator ViewModel(this Model b)
    {
        return new ViewModel { Foo = b.Foo.ToString() };
    }
}

[mklemarczyk]

@MovGP0 good idea, but it should be somehow described, how it would affect performance?

[yaakov-h]

@mklemarczyk how does adding a keyword affect performance? I assume you are referring to runtime performance here, not compiler performance.

[AdamSpeight2008]

Could we also extend the range operator to those allowed by F#.

[MovGP0]

@mklemarczyk at runtime, this is just an ordinary method call.

[mklemarczyk]

@MovGP0 It is not a ordinary method call. If you mean runtime, than language will keep in memory another method signature and spent time to get the proper when calling operator. If I'm right, right now operators are picked during the compilation time. So there is no additional look up time to get proper method for operator.

C# runtime do many things in the background, I wonder how implementing that extension operator will affect that. Can someone from IL specialist or runtime specialist make a statement on that?

[mklemarczyk]

@yaakov-h Try to imagine if many libraries will create the same operator. Which one C# need to pick than?
That feature affects the performance in many places. It is not adding a simple keyword.

Simple keyword is if you can create macro that will generate the same code that you can create without that keyword. Here the language itself need to be modified and how operator methods are stored in memory.

[jnm2]

@mklemarczyk

Try to imagine if many libraries will create the same operator. Which one C# need to pick than?

We have the exact same situation with extension methods and it has turned out to be not only not so bad but also valuable.

[mklemarczyk]

@jnm2 You do not see the point. When you are using extension methods you can force C# to use particular methods. There is no solution if you want to point particular operator in C# code. Operators have only single syntax when you want to invoke an operator method. In addition IntelliSense will do not help, because it starts showing after first character.

In my opinion it will make programming in C# more problematic than helping. I see too less possibilities of use such things.

Another question, Do you want to have access to private variables in operator extension methods?

For instance c + b and you can not do such thing for instance c MyOverload.+ b. It also will require to include particular namespace but you will also lose control.

It will became Declarative programming instead of Imperative programming.

[MovGP0]

The Problem you are addressing will exist with all operator overloads. So yes, we should think about that.

Instead of c + b it will require some fallback to express MyExtension.op_add(c, b).

[jnm2]

When you are using extension methods you can force C# to use particular methods.

The way you typically do this is by manipulating using and using static so that only the extension methods you want are in scope. In what situation is this not good enough to control extension operators too?

[yaakov-h]

@mklemarczyk:

That feature affects the performance in many places. It is not adding a simple keyword.

You still haven't outlined what performance will be affected and how

Your original comment was directed to @MovGP0, and his only comment above was the introduction of the this keyword to the declared extension operator. If that's your performance concern, please elaborate, if it isn't then please explain what your concerns are.

[dfkeenan]

Being able to define cast operators in a separate class would be AMAZING. When you are using UI and graphics libraries and they all define there own Rectangle/Point/Vector/Size/Matrix types it's not a great experience. Being able to define implicit cast operators would make integrating multiple libraries a whole lot nicer.

[frankhaugen]

That's a great point!