Discussion: Apply implicit operator for pattern matching

[jcouv]

@Logerfo commented on Tue Jan 09 2018

Context

Recently, I've opened this stackoverflow question, which brought me to #1047 (comment).
The idea is to apply implicit operators when matching unhandleable patterns (I really hope this word does in fact exist).

Scenario

So, considering the following struct:

public struct ReadOnly<T> where T : struct
{
   private T? value;
   public T Value
   {
      get => value ?? throw new InvalidOperationException("Value not set");		
      set
      {                        
         if (this.value.HasValue)
            throw new InvalidOperationException("Value already set");

         this.value = value;        	
      }
   }

   public bool HasValue => value.HasValue;

   public ReadOnly(T? value) => this.value = value;

   public static implicit operator T?(ReadOnly<T> value) => value.value; //attention here!

   public static implicit operator ReadOnly<T>(T? value) => new ReadOnly<T>(value);

   public static explicit operator T(ReadOnly<T> value) => value.Value;
}

We get:

var foo = new ReadOnly<int>(2);
if (foo is int bar) { } //CS8121 An expression of type 'ReadOnly<int>' cannot be handled by a pattern of type 'int'.
if ((int?)foo is int baz) { } //Compiles and resolves true.

Suggestion

When a pattern cannot be handled, the compiler should apply the implicit operator which allows the expression to be resolved, if any. If there are multiple possible implicit operators that would cover the issue, nothing should be done and the compilation error must prevail.
This is a suggestion, not a proposal, which means that no detail is final. Feel free to suggest changes or demonstrate barriers.

Why?

The compiler has some hard code for the Nullable<T> to work in this scenario. Implementing this suggestion would allow the struct to have a implicit operator T. If so, the hard code would not be necessary anymore, and users could achieve the same behavior with any type.

Alternative

One can just use a explicit conversion operator (cast) in order to achieve the expression resolution.

Unanswered questions

public struct ReadOnly<T> where T : struct
{
   //...
   public static implicit operator T?(ReadOnly<T> value) => value.value;
   public static implicit operator int(ReadOnly<T> value) => value.Value is int x ? x : throw new Exception();
   //...
}
var foo = new ReadOnly<int>(2);
if(foo is int bar) { } //what should happen?

public struct ReadOnly<T> where T : struct
{
   //...
   public static implicit operator T?(ReadOnly<T> value) => value.value;
   public static implicit operator int(ReadOnly<T> value) => value.Value is int x ? x : throw new Exception();
   //...
}
var foo = new ReadOnly<int>(2);
if(foo is int bar) { } //what should happen?

public struct ReadOnly<T> where T : struct
{
   //...
   public static implicit operator T?(ReadOnly<T> value) => value.value;
   public static implicit operator T(ReadOnly<T> value) => value.Value;
   //...
}
var foo = new ReadOnly<int>(2);
if(foo is int bar) { } //what should happen?

• Should the base class operators be considered? If yes, should the compiler look at the hierarchy for disambiguation or not?

Edit1: added "Why?" and "Alternative" sections.

---

@jcouv commented on Wed Jan 10 2018

This is a language design discussion. I'll move to csharplang. Thanks

[jcouv]

Tagging @gafter FYI

[DavidArno]

I'm tentatively 👍'ing this as I've run into issues with wanting patterns to handle implicit conversions. It's only tentative though as my gut feeling is that user-defined positional/active patterns might cover these scenarios, possibly making this unnecessary.

[gafter]

This would a bit undermine the similar behavior we intend to get for dynamic vs static checks. For example:

HasConversionToInt x = new HasConversionToInt(3);
if (x is int z) // succeeds?
object y = x;
if (y is int z) // fails?

[yaakov-h]

I find this useful, but potentially troublesome as @gafter outlined above.

@DavidArno How would you use active patterns for type conversion?

[Logerfo]

@DavidArno

user-defined positional/active patterns might cover these scenarios

According to @HaloFour, it doesn't.

@gafter

if (y is int z) // fails?

I think object should behave exactly the same as it does today, since it does not have any implicit conversions.
As for dynamic, I can't opine, since I don't know how it works today for pattern matching. I rarely use it.

[HaloFour]

@Logerfo

The exact design of that is still up in the air. It's possible that they might if you can write them as extension static methods and the extended type doesn't have to be static. Maybe something like this:

public extension IntPattern of int {
    public static bool Deconstruct(ReadOnly<int> ro, out int value) { ... }
}

But I can't see how that would work on T. It probably wouldn't.

As for dynamic, I can't opine, since I don't know how it works today for pattern matching. I rarely use it.

I believe he's referring to pattern matching against an expression of a different type, like object:

object o = new ReadOnly<int>(2);
if (o is int i) { ... }

The problem is that the compiler has no idea that o is a ReadOnly<int> and thus has no reason to look for implicit cast operators to int.

[Logerfo]

@HaloFour

The problem is that the compiler has no idea that o is a ReadOnly<int> and thus has no reason to look for implicit cast operators to int.

I think it shouldn't and that's not a problem.

public extension IntPattern of int

I wonder what's the reason for a name here lol

[HaloFour]

@Logerfo

I think it shouldn't and that's not a problem.

Well, given @gafter 's comment, it sounds like maybe he thinks that it should.

I wonder what's the reason for a name here lol

Extension members still have to exist in their own type, just like extension methods do today. Since that type would be a part of a public surface it's safer to have the developer explicitly define the name rather than have the compiler generate one.

[yaakov-h]

That’s a CLR limitation?

[DavidArno]

@yaakov-h,

How would you use active patterns for type conversion?

@Logerfo,

user-defined positional/active patterns might cover these scenarios
According to @HaloFour, it doesn't.

Ha, interpretation is in the mind of the reader, or some such. What @HaloFour shows in that comment is exactly what I was going to use as an example of how a user-defined pattern could handle such scenarios 😀

[Thaina]

I wish it should be a new keyword for convertible

I don't against the feature, its great. But we should leave is keyword to be the same reference object

Suppose

object a = new SomeClass();

if(a is SomeClass sc)
    sc.SomeProperty = 15; // a would be set property to 15

if(a is ImplicitConversionToSomeClass ic)
    ic.SomeProperty = 15; // if we allow implicit conversion here it would create new object to set value

So we should have keyword convertible or select for the purpose of difference object pattern matching

[yaakov-h]

// if we allow implicit conversion here it would create new object to set value

IIRC, this is already what happens with primitives and structs.

[Thaina]

@yaakov-h That's unavoidable but at least it common in C# for struct and class to have difference behavior. This proposal make class have an unpredictable behavior. Means it might or might not set the value to the original object

And if someone already have code like this it would be breaking change

[yaakov-h]

How about, and I'm only half serious on this:

if(a is ImplicitConversionToSomeClass ic)
    ic.SomeProperty = 15; // we allow implicit conversion here which does what it wants, including potentially creating a new object

if(a is really ImplicitConversionToSomeClass ic)
    ic.SomeProperty = 15; // implicit conversion cannot reach here

Or, the inverse,

if(a is ImplicitConversionToSomeClass ic)
    ic.SomeProperty = 15; // implicit conversion cannot reach here

if(a is kinda ImplicitConversionToSomeClass ic)
    ic.SomeProperty = 15; // we allow implicit conversion here which does what it wants, including potentially creating a new object

[Thaina]

@yaakov-h It too messy to append more keyword after is. And it should be inverse to keep consistency, no possible breaking change

I think

if(a maybe ImplicitConversionToSomeClass ic)
    ic.SomeProperty = 15; // we allow implicit conversion here which does what it wants, including potentially creating a new object

better