Pattern Matching on Generic Type Parameters

[TonyValenti]

I'd like to be able to write code like this:

var Samples = new object[] {
  new List<String>(), 32, null, new List<Int>(), new List<Person>(), "", 
};

foreach(var item in Samples){
  if(item is List<out var OfType>){
    Console.WriteLine($@"Item is a list of {OfType}");
  }
}

Basically I'd like to be able to easily detect and extract type parameters.

[HaloFour]

What are the use cases for wanting to do this? I can't think of any that don't involve reflection of some type.

I've proposed additional APIs to the BCL team to help reason about generic types. This scenario could pretty easily be covered by one of those APIs:

var Samples = new object[] {
  new List<String>(), 32, null, new List<Int>(), new List<Person>(), "", 
};

foreach(var item in Samples){
  if(item != null && item.GetType().Is(typeof(List<>), out Type elementType)) {
    Console.WriteLine($@"Item is a list of {elementType}");
  }
}

[alrz]

with recursive patterns it would get a lot less verbose:

if (item is (typeof(List<>), {var elementType})) {
   Console.WriteLine($"item is a list of {elementType}");
}

which is equivalent to:

item.Deconstruct(out var type, out var args);
if (type == typeof(List<>) && args.Length == 1) {
  var elementType = args[0]
  Console.WriteLine($"item is a list of {typeArgument}");
}

using a Deconstruct method:

static void Deconstruct(this object obj, out Type openType, out Type[] typeArguments) {
    var t = obj.GetType();
    openType = t.GetGenericTypeDefinition();
    typeArguments = t.GenericTypeArguments;
}

PS: probably better to define the extension on Type to enable recursive calls on the output.

Assert.True(typeof(A<B<int>>) is (typeof(A<>), {(typeof(B<>), {typeof(int)})}));

[bondsbw]

Just brainstorming, is this suggesting that the following somehow work, effectively extending the concept of generic type parameters to local variables?

public void AddIfCompatible(object list, object obj)
{
    if (list is List<var T> listT && objToInsert is T objT)
    {
        listT.Add(objT);
    }
}

And if that works then would type constraints be allowed?

if (list is List<var T> listT where T : int)
{ ... }

I'm having a hard time justifying this over simply adding a generic type parameter to the method. Keeping the API backwards compatible without introducing an overload (e.g. the method also works on non-generic lists)?

[TonyValenti]

@HaloFour -
I really like your APIs but there are a few issues that I foresee:

1. They're not refactoring-safe. If I move an generic type parameter around, I just broke a lot of code.
2. For classes that accept multiple generic type parameters, I'd like to be able to both specify certain ones and extract others. For example:

if(Source is Dictionary<int, out var ValueType>){
  //Only work if the dictionary has Keys of Int.  Who cares about the values.
}

[HaloFour]

@TonyValenti

Matching specific parameters is certainly possible with my API:

if(item != null
    && item.GetType().Is(typeof(Dictionary<,>), out Type keyType, out Type valueType)
    && keyType.Equals(typeof(int)) { ... }

That was a fairly common use case in my project.

You frequently move generic type parameters around?

Even so, I can't imagine that there are enough use cases to justify a special syntax for pattern matching generic type arguments. Given that whatever this pattern would be used for likely involves reflection odds are that would still break during said refactoring anyway. Between recursive patterns (and hopefully parameterized active patterns) you should be able to mix type matching in with pattern matching anyway, and hopefully with fairly decent syntax.

[gafter]

@TonyValenti How would this work? For example, how do you imagine this would be translated into existing C#? Or if that's not possible, into IL? Or if that's not possible, how would it be translated into machine language?

[sjb-sjb]

@HaloFour wondering why use a method on GetType() instead of extending the 'is' keyword as originally proposed by @TonyValenti ? Syntax seems nicer with the 'is' keyword.

I have often wanted this feature. When a generic type is defined one often wants to know whether or not a given object is "one of those" in order to provide special treatment such as invoking a certain method on the object (the method does not necessarily have the type parameter in its signature). The only other obvious approach to this is to factor out a base class of the generic type. There are many situations in which it is not very convenient to do that or where one is working with a pre-existing type.

[HaloFour]

@HaloFour

@HaloFour wondering why use a method on GetType() instead of extending the 'is' keyword as originally proposed by @TonyValenti ? Syntax seems nicer with the 'is' keyword.

IMO that's the wrong question. Why would you propose to extend the language instead of using a an API? Even if the language team jumped on this idea right now you wouldn't see such a feature for at least another year, but you could write a helper method this afternoon.

It's also a question of ROI. is might be nicer, but how often do you really need functionality like this? And under what circumstances would you use such functionality that didn't also require reflection so that you could do something with that generic type argument? IMO, the answer to both is "very infrequently", which makes the reward very low for this as a language feature.

[theunrepentantgeek]

FWIW, and for the benefit of anyone else finding this question, you can obtain the runtime type of a generic object (within certain limitations) at runtime and without using reflection.

The key is to remember that dynamic defers method overload resolution until runtime.

Taking the original example, and expanding it slightly to make something that compiles today:

using System;
using System.Collections.Generic;

namespace DynamicDemo
{
    public static class Program
    {
        public static void Main()
        {
            var Samples = new object[] 
            {
            new List<string>(), 32, null, new List<int>(), new List<Person>(), "", 
            };

            foreach(var item in Samples)
            {
                dynamic d = item;
                PrintIt(d);
            }
        }
        
        private static void PrintIt(object obj) 
        {
            Console.WriteLine($"Have object: {obj}");
        }
        
        private static void PrintIt<T>(List<T> list)
        {
            Console.WriteLine($"Have list of type: {typeof(T).Name}");
        }
    }

    public class Person
    {
        // ... elided ...
    }
}

Output is this:

PS> dotnet run
Have list of type: String
Have object: 32
Have object:
Have list of type: Int32
Have list of type: Person
Have object:

I've used this technique to good effect a handful of times.

As mentioned above, this technique does have a number of limitations - but it's faster than reflection, arguably easier to read than using reflection, and achieves many of the goals as the original request.

[HaloFour]

Not to nitpick but isn't that just relying on runtime reflection built-into the C# dynamic binder? I'm actually surprised that it's faster, I'd think that it would have to jump through pretty much all of the same hoops.

[theunrepentantgeek]

Not nitpicking at all! 😁

Yes, you've described exactly what it's doing. If memory serves (it's been a few years), benchmarking did show that it was faster, I think because the dynamic language runtime does some aggressive caching.

[sjb-sjb]

@theunrepentantgeek pretty cool! Comment, the type T in what you show has to be known in advance. In the original posting, I think the type is not known. I like the idea of a syntax identifying the reflected type, for example: if (item is IList<Type t>) { ... }

@HaloFour I think your APIs are worthy of having language syntax for them. Obviously a few other people have thought that having syntax for this would be a good idea, and you also are saying it is a common use case. I feel it would make for much more intuitive and streamlined coding.

I don't see anything wrong with the idea of "is" being extended to have reflection-based uses. The pattern-matched variable ("list" in the following example) could be dynamic and then depending on the amount of analysis done by the compiler one could generate static errors in some cases.

 if (item is IList<Type t> list && x is t) { 
      list.Add( x);  // No compile-time or run-time error, Add is a unary method of IList<T> for all T, and x is t at run time.
      list.Eat( x); // Possible compile-time error, Eat is not a member of IList<T> for any T
      list.Add( y); // No compile-time error, but run-time error if y is not t. Also compile-time error if type of y is known and does not satisfy generic type constraints of IList<T>. 
 }

In the above one can also imagine writing "x is t xx" and then having xx be dynamic but again restricted to invoking members of type t. In this case the errors would be run-time only since obviously there is no compile-time information about t.

Not saying all this is easy to do :-).

[EvilVir]

This would be great feature to have. Take, for example, following situation:

I have bunch of interfaces that entity class can implement, like ITimestampable, ISoftdeletable, IUserRelated etc. I have also set of extensions method that helps setup these kind of entities:

        public static void IsTimestamped<T>(this EntityTypeBuilder<T> builder)
            where T : class, ITimestampedEntity
        {
            builder.HasIndex(x => x.DateCreated);
            builder.Property(x => x.DateCreated).IsRequired();
        }

        public static void IsSoftDeletable<T>(this EntityTypeBuilder<T> builder)
            where T : class, ISoftDeletableEntity
        {
            builder.HasIndex(x => x.IsDeleted);
            builder.Property(x => x.IsDeleted).IsRequired();
        }

etc.

Now I would love to write ApplyAllPossible<T> method like this:

		public static void ApplyAllPossible<T>(this EntityTypeBuilder<T> builder)
			where T : class
		{
			if (T is ITimestampedEntity)
			{
				IsTimestamped(builder);
			}

			if (T is ISoftDeletableEntity)
			{
				IsSoftDeletable(builder);
			}

			// etc...
		}

Or, slightly different:

		public static void ApplyAllPossible<T>(this EntityTypeBuilder<T> builder)
			where T : class
		{
			if (builder is EntityTypeBuilder<T2> castedBuilder where T2 : ITimestampedEntity)
			{
				IsTimestamped(casteBuilder);
			}

			if (T is EntityTypeBuilder<T2> castedBuilder where T2 : ISoftDeletableEntity)
			{
				IsSoftDeletable(castedBuilder);
			}

			// etc...
		}

[sab39]

If pattern matching on generic types happens, I'd like to see it be capable of something more or less like:

public static bool HasValue<T>(T value)
{
  if (T : class)
  {
    return value is not null;
  }
  else if (T is Nullable<var U>)
  {
    return value.HasValue; // this compiles because the compiler knows that value is of type T and that T is Nullable<something>
  }
  else if (T : struct)
  {
    return true;
  }
  else
  {
    throw new InvalidOperationException();
  }
}

[gafter]

You can replace that whole body by value is not null.

[jnm2]

And, the JIT even inlines true when T can't be null.

[rjgotten]

Pattern matching on generic types would be seriously useful for scenarios where you don't have an instance, which could be covered by the dynamic binder already, but are working directly on a type. I have some code here which needs to create a dynamic property accessor that can either be pointing to an IEnumerable<> sequence or to a single value, and which then has to follow up by doing something with the strongly typed value.

In an ideal world, I'd be able to:

public class HandlerFactory<TRoot>
{
  public static bool TryCreateHandler<TValue>(string propertyName, out IHandler<TRoot, TValue> handler)
    => TValue is IEnumerable<var TItem>
      ? new MultiItemHandler<TItem>()
      : new SingleItemHandler<TValue>();
  
  private sealed class MultiItemHandler<TItem> : IHandler<TRoot, IEnumerable<TItem>> 
  {
    // ...
  }
  
  private sealed class SingleItemHandler<TValue> : IHandler<TRoot, TValue> 
  {
    // ...
  }
}

Alas that doesn't exist, so either I have to take on a heap of reflection magic creating generic delegates and recasting their type parameters. (Libraries exist for this. But I still hate using it. Feels like black magic.)

Or, I have to use type constraints and a second generic parameter, i.e.

public class HandlerFactory<TRoot>
{
  public static bool TryCreateHandler<TValue>(string propertyName, out IHandler<TRoot, TValue> handler)
    => new SingleItemHandler<TValue>();
    
  public static bool TryCreateHandler<TCollection, TValue>(string propertyName, out IHandler<TRoot, TValue> handler)
    where TCollection : IEnumerable<TValue>
    => new MultiItemHandler<TValue>();
  
  private sealed class MultiItemHandler<TItem> : IHandler<TRoot, IEnumerable<TItem>> 
  {
    // ...
  }
  
  private sealed class SingleItemHandler<TValue> : IHandler<TRoot, TValue> 
  {
    // ...
  }
}

But then, any callers also have to supply both arguments - which is really redundant and an awful API surface.

[jyrkive]

This feature would be a handy improvement for generic math. I have an Avalonia value converter for turning numeric types into hexadecimal numbers. It would be convenient if this worked:

class HexConverter : IValueConverter
{
    public object? Convert(object? value, Type targetType, object? parameter, CultureInfo culture)
    {
        if (value is IBinaryInteger<> val && targetType.IsAssignableTo(typeof(string)) && parameter is string precision)
        {
            return val.ToString("X" + precision, null);
        }

        return new BindingNotification(new InvalidCastException(), BindingErrorType.Error);
    }
}

But it doesn't, so at the moment I need to test for necessary integer types by hand instead of merely testing for IBinaryInteger and calling it a day.

[rjgotten]

After seeing this pop back up again, and thinking about it again - I now realize:
this feature can't currently happen because it is non-deterministic and ambiguous in the returned generic type.

If a type implements both IEnumerable<string> and IEnumerable<int> what would a proposed

if (foo is IEnumerable<var T>)
{
  // ...
}

use as the type T ?
string or int?
Under which conditions? First matched? How is 'first' determined? First position in the inherit/implement list of the class definition? Suddenly ascribing meaning where none existed before?

Getting this to work correctly would require C# to have support for TypeScript-like type unions and type intersections, because then T would be string|int which could trickle down into further pattern matches for specific implementations.

[sjb-sjb]

@rjgotten good point!

I’ve often thought that type intersections and unions would be a very useful thing to have. Having said that, it would be quite the departure for c#.

A simpler approach would be an array output if (x is IEnumerable<Type[] types>) { … }.