Proposal: switch on System.Type

[gafter]

@alrz commented on Tue Jan 26 2016

When it comes to runtime type comparison, there are multiple ways to do so, it's more cumbersome if you want to do it multiple times with if else. it would be really nice if we could literally switch on System.Type or System.RuntimeTypeHandle and compiler choose the fastest way, like using TypeHandle.

Type type = ...;
switch(type) {
  case typeof(Foo): ... break;
  case typeof(Bar): ... break;
}

---

@GeirGrusom commented on Tue Jan 26 2016

It's planned that you can switch on type in C# 7.

I think it will look like this:

switch(baz)
{
    case Foo foo:
        foo.DoFoo();
        break;
    case Bar bar:
        bar.DoBar();
        break;
}

---

@alrz commented on Wed Jan 27 2016

@GeirGrusom That's not what I'm talking about.

---

@orthoxerox commented on Wed Jan 27 2016

Well, it would be nice if types were first-class citizens, but that would require CLR support, I think.

---

@alrz commented on Wed Jan 27 2016

@orthoxerox I even suspect that this behavior can be neatly implemented as an extension is operator (if that would be possible). So, no CLR support is required at all.

---

@HaloFour commented on Wed Jan 27 2016

The CLR is fully capable of handling the logic. The question is how such a statement should be expanded. I'd imagine it would produce the same IL as a series of if/else statements since the IL switch opcode only works when the values are a range starting at 0 which the runtime type handle would not be.

Type type = obj.GetType();
switch (type)
{
    case typeof(Foo):
        Console.WriteLine("Foo!");
        break;
    case typeof(Bar):
        Console.WriteLine("Foo!");
        break;
    case typeof(Baz):
    default:
        Console.WriteLine("Baz or Something Else!");
        break;
    case typeof(Frob):
        Console.WriteLine("Frob!");
        break;
}

effectively equivalent to:

Type type = obj.GetType();
if (typeof(Foo).IsEquivalentTo(type))
{
    Console.WriteLine("Foo!");
}
else if (typeof(Bar).IsEquivalentTo(type))
{
    Console.WriteLine("Bar!");
}
else if (typeof(Frob).IsEquivalentTo(type))
{
    Console.WriteLine("Frob!");
}
else
{
    Console.WriteLine("Baz or Something Else!");
}

---

@alrz commented on Wed Jan 27 2016

@HaloFour switch with pattern-matching already turns to mix of if, else and switch (at least this is what F# does). So I assume this can be done in a similar way. Also, I don't know about IsEquivalentTo but comparing TypeHandle causes no type load and will be emitted directly to IL (see the link in the opening post).

---

@HaloFour commented on Wed Jan 27 2016

@alrz In IL it's all conditional branch opcodes, unless the condition meets the incredibly narrow requirements to make it work with switch. I assume that ADTs in F# have an incrementing tag field which do meet those requirements.

If if (typeof(Frob).TypeHandle.Equals(type)) is appreciably more efficient then sure, that's probably what the compiler should emit.

---

@drewnoakes commented on Thu Jan 28 2016

Should this only match exact types? What about derived types? Would case typeof(object) catch everything or only new object()? Either way it's going to surprise someone somewhere.

---

@alrz commented on Thu Jan 28 2016

@drewnoakes That would be actually nice but then it will depend on the order and we might lose TypeHandle optimization.

---

@AdamSpeight2008 commented on Thu Jan 28 2016

Or it'll turn it into a dictionary lookup, similar to VB.net's Select Case

---

@CnSimonChan commented on Sat Apr 09 2016

Seems you can do it in future branch

But the compiler will crash when compiling it :(

---

@alrz commented on Sat Apr 09 2016

@CnSimonChan I think that's because switch is already relaxed to accept any expression type (depending on the branch you're on) and this doesn't seem to be something that you'd get it "for free" via pattern-matching. So I think they should make it explicitly an error or consider implementing it.

---

@gafter commented on Mon Apr 11 2016

@CnSimonChan Reported as #10459

---

@gafter commented on Mon Apr 11 2016

Since we have to fix the compiler crash, lets just make this work.

---

@weitzhandler commented on Mon Mar 06 2017

A compelling feature I come a lot across with. I'd love to see this implemented.

[Spongman]

I just ran into this and was really surprised that, given c#7's new switch statement stuff, that this simple case was still not covered.

there is a rather long-winded workaround, however:

Type type = ...;
switch(type) {
  case Type t when t == typeof(Foo): ... break;
  case Type t when t == typeof(Bar): ... break;
}

[YairHalberstadt]

@gafter

Do you think this could be championed? You indicated above that you thought it was worth doing, and I think it fits nicely in with pattern matching.

I would be happy to implement it.

[davidnmbond]

@gafter @YairHalberstadt please let me know if I can help!

[gafter]

@YairHalberstadt I am not interested in championing this.

[YairHalberstadt]

@gafter

Understood. That's a pity. It's only a minor feature, but it comes up quite regularly. For example you suggested I use it in dotnet/roslyn#32843 (comment)

EDIT:

I was talking nonsense. You didn't suggest that. You suggested something else that didn't compile for a different reason.

[gafter]

For example you suggested I use it

That was not what I meant by "switching on the type". I meant something like

switch (someObject)
{
    case SomeType1 s1:
        ....
    case SomeType1 s2:
        ...
    case SomeType3 s3:
        ...
}

I'm working on our options for making this compile reliably to a constant-time dispatch in future versions (likely C# 9 or so) without any source changes.

[Happypig375]

My TypeConverters will look so much better when this is implemented!

[MgSam]

I do this more operation far more than I do any other scenario where a switch statement/expression would be useful. And I always have to use if statements. I hope the LDT triages this issue at some point.

[soenneker]

Following - also interested in this feature.

[pinkfloydx33]

Same. This came up in an SO post I commented on the other day. Would be nice to see, I can think of a few places I could clean up if this were implemented.

[ManuelKugelmann]

I quite regularly stumble upon this missing feature - it would be a great addition to c#!

[BreyerW]

While i personally dont but when i do i really wish for cleaner switching on types too. Giant if elses with multiple typeof looks awful and after certain threshold becomes hard to read

[anaximander23]

Just hit this doing some stuff with custom model binding in ASP.NET; I have a value which is string, and I have a ModelMetadata instance with a property UnderlyingOrModelType that is an instance of Type. If I could just do switch (prop.UnderlyingOrModelType) with cases for each type that needs special handling, it'd be great.

[mburbea]

I've come across scenarios where this can be used as an acceptable replacement if you know the type in question is a struct. e.g.

public string M<T>() where T:struct => default(T) switch {
   byte => "byte",
   sbyte => "sbyte"
   _ => "Not a byte or sbyte"
};

Unfortunately, doesn't really work when all you have is a type and you want to switch as ref types default is null.

[Tinister]

Try public string M<T>() => System.Runtime.Serialization.FormatterServices.GetUninitializedObject(typeof(T)) switch { ... for all types. 😉

[mburbea]

well the advantage of the above approach is that is that it get optimized away into nothing.
https://sharplab.io/#gist:e62ff8b898ce2f31fc13783bde391278

When you use FormatterService it generates a lot more code::
https://sharplab.io/#gist:e905ea465977d5c88ede6e7ed4443c43

[wolgemoth]

This is a feature I have been waiting for as I use this exact pattern in my current project. I prefer switch statements to else if chains because they very clearly communicate their purpose (whereas an else if chain can be ambiguous at times).

Seeing how they both compile into basically the same thing, I can't imagine this functionality being too hard to add in.

[MgSam]

FYI- I just noticed Github Discussions doesn't seem to have a way to sort by "Thumbs Up" of the original post - you have to separately up vote the issue itself up. So to keep visibility on this issue - I suggest that all the people asking for it do that in addition to the thumbs up.

[bernd5]

You can do it now but with a slightly different syntax:

using System;

Type type = ...;
switch(type) {
  case var x when x == typeof(int):
     break;
  case var x when x == typeof(string):
     break;
}

In my eyes this is sufficent.

And it works for switch expressions, too:

var typename = GetValue()?.GetType() switch
{
    var type when type == typeof(int) => "int",
    var type when type == typeof(string) => "string",
    _ => throw new NotSupportedException()
};

In CSharp 8 we introduced the "Constant-Pattern". Perhaps you could propose a "Non-Constant-Pattern" with a link to this discussion.

System.Type is a very well known immutable type - but it could be nice for other immutable types like records, too.
But in general one should avoid the usage of runtime-type-objects if it is doable with compile-time-types.

[BreyerW]

Hardly sufficient. All i can say good thing about it is, it works. But it is actually more verbose than traditional giant if/else especially when one needs to stack conditions on top of these (very rare yes but not unlikely) so 0 improvement for this particular case.

[jnm2]

The constant pattern was introduced in C# 8, by the way.

[msedi]

Does the suggestion also take into account code elision? Currently in generic methods checks against a typeof() is completely elided if possible. The switch with the type should also take this into account.

[GeirGrusom]

Does the suggestion also take into account code elision? Currently in generic methods checks against a typeof() is completely elided if possible. The switch with the type should also take this into account.

Isn't that a JIT issue rather than a compiler issue?

[bernd5]

Which suggestion? If a type check is statically know (at generic function instantiation) code can be eliminated by the compiler / JITer.
But here type is a runtime type - how should the jitter know that such checks are always false?

[msedi]

@bernd5: I was assuming the switch should work on typeof() which is currently supported by the JIT to be elided if the statement is done wit if..then.else checks. I think it should work the same way, the switch should degenerate to one single case (the switch is indeed removed), if this is different to if..then..else no one will recognize the difference.

But I'm not sure if I fully understood the proposal.

[bernd5]

@msedi
The possibilities to elide some cases / code in case of runtime-type checks are very limited.
You could elide for example: typeof(T) == typeof(int) when T is known.
But this seems to be nearly impossible with arbitrary System.Type's - they are more or less just a pointer, like any other object.

[msedi]

@bernd5. Yes. You are right. I didn't see this.

[davidnmbond]

This issue was linked to from here: https://www.reddit.com/r/csharp/comments/q5zsbr/switcht

The requested example:

private bool TypeIsCool<T>()
    => T switch
    {
        string => true,
        bool => false,
        _ => throw new NotSupportedException($"{typeof(T).Name} is not supported")
    };

This would be great syntactic sugar for the following best answer in that thread:

static bool TypeIsCool<T>()
    => typeof(T) switch
    {
        _ when typeof(T).Equals(typeof(string)) => true,
        _ when typeof(T).Equals(typeof(bool))=> false,
        _ => throw new NotSupportedException($"{typeof(T).Name} is not supported")
    };

This doesn't look to difficult to implement, the meaning is clear and it is narrow in scope (just the switch statement).

[DavidArno]

This doesn't look to difficult to implement, the meaning is clear and it is narrow in scope (just the switch statement).

The problem with that is that it's more of a hack than a true solution as it's not then a true pattern. For example, I have a genuine line in my code that I'd love to express as:

if (T is T1 or T2 or T3 or T4) ...

which this proposal wouldn't cover. In addition, I don't want to have to write your solution in the way you do as the throw isn't making use of pattern matching. I'd want to express it as:

private bool TypeIsCool<T>()
    => T switch
    {
        string => true,
        bool => false,
        var t => throw new NotSupportedException($"{t.Name} is not supported")
    };

The best solution I've come up with so far to work around this missing feature is to introduce a new Type<T>:

public readonly struct Type<T>
{
    private static readonly Type<T> Instance = new();
    private static readonly Type TType = typeof(T);
    public static Type<T> Value { get; } = Instance;

    public string Name => TType.Name;
}

This then allows your example to be written as:

static bool TypeIsCool<T>()  => Type<T>.Value switch {
    Type<string> => true,
    Type<bool> => false,
    var t => throw new NotSupportedException($"{t.Name} is not supported")
};

This approach let's me express that if I mentioned at the start as:

if (Type<T>.Value is Type<T1> or Type<T2> or Type<T3> or Type<T4>) ...

It's not perfect as too much boxing of the struct occurs for my liking and it's still too "noisy", but it possibly points the way to a true pattern-based solution for testing Type values and generic parameters.

[Khaos66]

I was facing this use case today as well and created #5687 but was directed to this discussion.

private int ToInt() => _value switch {
   int i => i,
   long l => (int)l,
   _ => default
}

private int ToLong() => _value switch {
   int i => i,
   long l => l,
   _ => default
}

public T As<T>()
{
   T x = default;
   return x switch
   {
      int when ToInt() is T i => i,
      long when ToLong() is T l => l,
     _ => default
   }
}

But I'm more concerned about performance. T x = default is a killer, when T is a complex struct, that can't be null.

Thinking outside the box

Maybe instead of having one generic method with a switch, we could have multiple methods?

public int As<T>() where T is int 
{ ... }

public long As<T>() where T is long 
{ ... }

[bernd5]

What you could do today (without allocating a large struct on the stack) is:

using System;

#nullable enable

IMyConvertibel c = new Container<int>(12);
var l = c.As<long>();
Console.WriteLine(l);
var i = c.As<int>();
Console.WriteLine(i);

interface IMyConvertibel{
	T? As<T>();
}

class Container<X> : IMyConvertibel
{
    X _value;

    public Container(X value)
    {
        _value = value;
    }

    private int ToInt() => _value switch
    {
        int i => i,
        long l => (int)l,
        _ => default
    };


    private long ToLong() => _value switch
    {
        int i => i,
        long l => l,
        _ => default
    };

    public T? As<T>()
    {
        return typeof(T) switch
        {
            var t when t == typeof(int) => Cast(ToInt()),
            var t when t == typeof(long) => Cast(ToLong()),
            _ => throw new NotImplementedException($"As<{(typeof(T).Name)}")
        };
		
        T Cast<S>(in S s){
	        ref var refVar = ref System.Runtime.CompilerServices.Unsafe.AsRef<S>(s);
	        ref var refT = ref System.Runtime.CompilerServices.Unsafe.As<S, T>(ref refVar);
	        return refT;
        }
    }
}

[quetzalcoatl]

public int As() where T is int
public long As() where T is long

Wouldn't it effectivelly pull half of C++ template specialization into C#?
The other half being SFINAE, which we also don't have in C# at the moment.
That all would be awesome, but IMHO won't going to ever happen in C# :)

[ThaDaVos]

So it seems the above hasn't got any solution still - I ran into this when working on creating a custom DataContractResolver - sadly typeof cannot be used inside the switch expression and the other patterns aren't that useful especially as I am trying to swtich as follows:

    public override bool TryResolveType(Type type, Type? declaredType, DataContractResolver knownTypeResolver, out XmlDictionaryString? typeName, out XmlDictionaryString? typeNamespace)
    {
        return (type, declaredType) switch
        {
            (DateOnly, DateOnly) => resolveTypeToXML(typeof(DateOnly), out typeName, out typeNamespace),
            _ => knownTypeResolver.TryResolveType(type, declaredType, knownTypeResolver, out typeName, out typeNamespace)
        };
    }

Gives me the error An expression of type 'Type' cannot be handled by a pattern of type 'DateOnly'.

[HaloFour]

Interest would come from demonstrating value through use cases. I wonder how many of those math use cases would be better solved through numeric generic constraints now, though. I don't believe it would require any runtime support, it's more or less just syntax candy.

[msedi]

@HaloFour:

I wonder how many of those math use cases would be better solved through numeric generic constraints now

True for the math cases, but I think for example the Vector<T> implementation still require it since the individual intrinsics (Sse2, etc) are not generic itself.

[DavidArno]

For all of the technicalities of "what is a constant", the only thing preventing switch on Type from being implemented is enough interest in doing so.

This is true. Currently there's no real interest amongst the language team to address this. So we all sit and wait for the day when another team in MS suddenly has a need for it as it'll then likely happen soon after... 😇

[hughesjs]

@hughesjs as there are always a lot of costs involved in the process of developing a compiler feature, the question should not be "why can't we make?", but "why should we make?" instead. Besides "why", we should also have a clear vision of "how" (since there are virtually infinite ways of achieving certain behavior and edge cases to be ruled) and "when" (since there are other feature requests to be considered).

Sorry, to clarify, my "why" was more if there were any reasons as to why it was theoretically impossible/impractical without huge language design changes that I was unaware of, not from a project feasibility standpoint.

[GabeSchaffer]

I think that the switch use case isn't as big as the general ability to use typeof expressions in patterns. I have a lot of expression processing code that has to do different things based on the types involved, and being able to match types in patterns would make my code a lot nicer.

Right now I have some code like this:

// look for bool Enumerable.Contains<T>(this IEnumerable<T> source, T value)
else if (expr is MethodCallExpression call)
{
    if (call.Method.Name == "Contains")
    {
        if (call.Method.DeclaringType == typeof(Enumerable))
        {
            var needle = call.Arguments[0];
            var haystack = call.Arguments[1];

but it would much prefer to write this:

// look for bool Enumerable.Contains<T>(this IEnumerable<T> source, T value)
else if (expr is MethodCallExpression {
    Method: { Name: "Contains", DeclaringType: typeof(Enumerable) },
    Arguments: [ var haystack, var needle ] })

Every time I write something like

node.Method is { Name: "op_Equality" or "op_Inequality" } method && method.DeclaringType == typeof(string)

I wish I could write it as

node.Method is { Name: "op_Equality" or "op_Inequality", DeclaringType: typeof(string) }

[Xyncgas]

Maybe we should first turn switch statement to F# switch statement, then in that prototype add support for switch to do type checking like we can in F#, and release them together under a new brand called the new switch

[ShalokShalom]

That sounds complicated to say the least?

[TahirAhmadov]

I also need this feature. One key aspect to remember here is that most of the code is already done for strings, so allowing types is literally just lifting a restriction. (Granted, adding typeof() to cases may be extra work. )

[RenderMichael]

This issue and many adjacent ones could be solved if typeof() was known to return a const-like result

[Xyncgas]

Like in C++
The problem is if you give a function an object at run time you have to do run time checking to know its type : who knows what you gave it then

[msedi]

Just out of curiosity, Type has a GUID property. Would it make sense to switch on this one?
I'm not sure how stable this is because I made the experience that in ReflectionOnlyLoads it makes a difference (!?).

[huoyaoyuan]

You can't switch on Guid either because it's not a constant. It's only available for COM interop types. Achieving the GUID also has heavy overhead.