Introduction

In C#, switching on runtime type is a normal pattern, but the best syntax depends on the language version. Modern C# uses type patterns in switch expressions or switch statements, while older code often fell back to if with is checks or manual type comparisons.

Modern C# Type Pattern Matching

A clean current approach is a switch statement with type patterns.

1using System;
2
3static string Describe(object value)
4{
5    switch (value)
6    {
7        case int i:
8            return $"int: {i}";
9        case string s:
10            return $"string: {s}";
11        case DateTime dt:
12            return $"date: {dt:yyyy-MM-dd}";
13        case null:
14            return "null";
15        default:
16            return "unknown";
17    }
18}

This is usually what people mean today by “switch on type.”

switch Expression Version

If the logic is purely value-to-value mapping, a switch expression can be even clearer.

1static string Describe(object value) => value switch
2{
3    int i => $"int: {i}",
4    string s => $"string: {s}",
5    DateTime dt => $"date: {dt:yyyy-MM-dd}",
6    null => "null",
7    _ => "unknown"
8};

This is concise and works well when each branch returns a single result.

Older Alternatives

Before type patterns were available, developers often used if chains.

1if (value is int)
2{
3    // handle int
4}
5else if (value is string)
6{
7    // handle string
8}

That still works, but modern pattern matching is usually easier to read and less repetitive.

Exact Type Versus Assignable Type

There is an important semantic difference between checking the runtime type exactly and checking whether an object is assignable to a base type or interface.

Pattern matching with case BaseType x: matches derived types too. If you need exact type equality, compare value.GetType() to a specific type instead.

That distinction matters in inheritance-heavy code.

A Practical Example With Interfaces

1interface IMessage {}
2class Email : IMessage {}
3class Sms : IMessage {}
4
5static string Route(IMessage message) => message switch
6{
7    Email => "email-queue",
8    Sms => "sms-queue",
9    _ => "default-queue"
10};

This shows why type-based switching is useful: it can express dispatch logic cleanly when the runtime shape matters.

When Not to Switch on Type

A type switch is sometimes a code smell. If the code keeps branching on concrete types everywhere, you may really want polymorphism instead.

For example, if each type knows how to describe or process itself, a virtual method or interface method may be cleaner than repeated external type checks.

So the right question is not only “can I switch on type,” but also “should this behavior live inside the type instead.”

Common Pitfalls

Pattern Matching Can Add Conditions

Modern C# patterns can also include guards, which makes them useful for type-plus-condition logic instead of plain type dispatch only.

1return value switch
2{
3    int i when i > 0 => "positive int",
4    int => "non-positive int",
5    _ => "other"
6};

The most common mistake is forgetting that a base-type case can also match derived instances, which changes branch selection.

Another mistake is using type switches where polymorphism would express the design more cleanly.

Developers also often omit a null case and then debug a surprising NullReferenceException later.

Summary

• Modern C# supports switching on type through pattern matching.
• 'switch statements and switch expressions both work well for this.'
• Type-pattern matches are based on assignability, not always exact type equality.
• Include a null case when the input may be null.
• If type switching spreads everywhere, consider whether polymorphism would be better.