Proposal: Pattern matching on type

[bondsbw]

Allow simplified pattern matching syntax to compare types.

Given types T and U (either of which may be a generic type parameter), allow the expression

T is U

which would expand to

typeof(T) == typeof(U)

Example

void Foo<T>()
{
    if (T is Bar) { ... }
}

which is equivalent to

void Foo<T>()
{
    if (typeof(T) == typeof(Bar)) { ... }
}

Alternate consideration

Allow derived types to meet the condition. The original expression would then expand to

typeof(T) == typeof(U) || typeof(T).IsSubclassOf(typeof(U));

So

string is object // true

[YaakovDavis]

Let's throw in some additional ideas:

T is IEnumerable<_>

T is Dictionary<int, _>

T is List<Dictionary<_,_>>

T is IEnumerable<var itemType> //itemType, of type Type is introduced to the scope

T is (T1, T2) //matches against a tuple type

T is T2[]

T is _[] //matches against any array type

[yaakov-h]

How about typeof(U).IsAssignableFrom(typeof(T))?

This would then allow expressions such as int[] is IEnumerable<int> etc.

[bondsbw]

@YaakovDavis Those are interesting. I'm not entirely sure if there would be a fundamental difference between T is Dictionary<,> and T is Dictionary<_,_>. Maybe so. Anyway, I'm a bit confused about this one:

T is IEnumerable<var itemType> //itemType, of type Type is introduced to the scope

[bondsbw]

@yaakov-h I think detecting interface implementation is compelling. Though, I believe IsAssignableFrom() may yield false positives, for example typeof(int?).IsAssignableFrom(typeof(int)) returns true.

[YaakovDavis]

@bondsbw
The above is borrowed from pattern matching on values.

x is Foo f;

is equivalent to:

Foo f = default(Foo);
if(x is Foo)
   f = (Foo)x;

Similarly, the following:

T is IEnumerable<var itemType>;

is equivalent to:

var typeOfT = typeof(T);

Type itemType = null;
if(typeOfT.IsGenericType &&  typeOfT.GetGenericTypeDefinition() == typeof(IEnumerable<>))
{
   itemType = typeOfT.GetGenericArguments()[0];
}

(The actual translation is even more complex, as we need to consider also types implementing IEnumerable<>).

[yaakov-h]

@bondsbw So given:

int x = 4;
if (x is int? y) { // ... }

Should we say this is a valid case, or not? My initial reaction is "yeah, why not".

[lachbaer]

My initial reaction is "yeah, why not".

Because an int is not a Nullable<int>, ar least not in an inheritance way. That's rather a case for an as pattern matching (if there was one).

if (x as int? y) { ... }

[bondsbw]

@yaakov-h

I can't say I have a firm opinion. Though I'm not sure that x is int? y is necessarily the same as int is int?.

[bondsbw]

And actually, I didn't realize until I just tried it, that your code doesn't compile with C# 7. Nullable types can't be used in type patterns? It's due to CS8116. The reverse is legal:

int? x = 4;
if (x is int y) { ... }

That might play into how this proposal should work, I'm not sure.

[Logerfo]

@bondsbw what do you mean with "doesn't compile"? Yes it does. And as far as I know, x is int and x is int? always return the same value.

[bondsbw]

@Logerfo That does compile, but x is int? y does not.

(And to be clear, the CS8116 is specifically for the expanded version x is Nullable<int> y. The difference in those errors was recently pointed out at dotnet/roslyn#16708.)

[Logerfo]

@bondsbw Oh, that's confusing. My bad, thanks for the clarification!

[jnm2]

@YaakovDavis

(The actual translation is even more complex, as we need to consider also types implementing IEnumerable<>).

And also types implementing IEnumerable<> multiple times with varying type parameter. (Sounds silly for IEnumerable<>, but I have run into this with other interfaces like IComparable<>.)

T is IEnumerable<var itemType> is quite exciting because I have burned so much time writing reflection code and getting it correct. However, the most natural type of the local itemType would be IReadOnlyCollection<Type> rather than Type.

All these ideas are amazing nice-to-haves which I've long felt were lacking in the language, and yet by the same token I can't imagine the LDT prioritizing them over other new features.

[HaloFour]

In my opinion the alternate, where subclasses and interfaces would match, would make more sense.

@YaakovDavis @jnm2

Check out the extensions to reflection that I've submitted to CoreFX here: https://github.com/dotnet/corefx/issues/644

if (obj != null && obj.GetType().ImplementsInterface(typeof(IDictionary<,>), out var keyType, out var itemType)) {
    // do stuff here
}

It makes reflection with generics so much easier. And please weigh in because the BCL team seem to not understand how ridiculously awful the reflection situation has been since the introduction of generics.

I'd not be at all opposed to such matching existing in the language as well, but the compiler would be forced to output some nasty boilerplate code.

[jnm2]

@HaloFour What does your ImplementsInterface do for multiple implementations, throw?

I added generic type parameter inference to AutoMapper a year ago so that ConvertUsing could figure out how to use an open-generic user defined type implementing ITypeConverter<,> one or more times.
My second ever pull request was LuckyPennySoftware/AutoMapper#1207 😆

I'd not be at all opposed to such matching existing in the language as well, but the compiler would be forced to output some nasty boilerplate code.

Yes, they designed the type system, better them than me maintaining that. 😁

[HaloFour]

@jnm2

What does your ImplementsInterface do for multiple implementations, throw?

Wasn't a situation I specifically guarded against. The implementation I provided in the gist attached to that issue would find one of the implementations and return true with its generic type arguments but the result would not be deterministic.

Yes, they designed the type system, better them than me maintaining that. 😁

Well, a different team, but they're certainly closer to each other than we are to either of them. And even if CoreFX and eventually BCL adopted better reflection APIs the compiler likely couldn't take advantage of it if there would be any expectation of targeting older frameworks.