The switch statement only accepts numeric and string values, which means that you can't use a Type value. You could switch off of the ToString() value of the type, but that's as close as you'll get. I would recommend using an enum instead.

In general, however, this rarely proves to be a good design choice. You are better off passing in a delegate or a object that implements an interface (or even a generic type parameter) to define the "strategies" for handling different types.

This is a common question about designing and writing generic types - namely the ability to perform entirely different actions based on the type of the generic type parameters. I tend to view this as a code smell that you may not be using generics as they were intended and your design is "going against the grain", so to speak.

However, in some cases it is indeed necessary to perform processing that varies by type, in which case passing in a separate type (either to the constructor as another generic parameter) allows you to separate the different concerns into "strategies" that are more extensible, cleaner, and less coupled to the implementation of the generic class. An example might be:

Now you can write different implementations of IOperation<T> that are appropriate to different types (integers, floating point numbers, complex numbers, matrixes, etc). The generic class Calculator<T,TOp> is then separate from the operations that vary by type, but is free to compose them as it sees fit.

In .NET 4.0 it's possible to use dynamic to dispatch to overloads of one or more methods that are specialized for certain types. This approach, while simpler, incurs the performance penalty of essentially invoking the compiler at runtime to figure out which method to invoke. Althought, the DLR does to a reasonably good job of caching this information at the call site, which can amortize the cost if you will invoke the method multiple times.

Note that if you are switching on the type of a generic then you probably have a design flaw somewhere. The whole point of generics is that they are generic; you shouldn't care what the actual type is.

Peter Hallam proposes two unsatisfactory methods for disambiguating which switch branch to execute, but my initial reaction to the disambiguation problem would be to use the same behavior as an overloaded method with several parameter options. Why could you not use that same behavior in a switch statement?

@SLaks: Generics can handle this case more gracefully if you apply the "strategy" design pattern. Rather than switching on the type, supply an additional generic parameter that provides operations that are specific to the type the generic is being constructed for (I threw together a simple example in my answer). I tend to agree with Eric that switching on the type often implies a design flaw.

@SLaks: First, I'm not sure I agree that this design makes the method more cumbersome to call. Perhaps more cumbersome to write correctly - but the complexity can (mostly) be hidden from consumers. Second, when you create a generic class, it's users reasonably assume that it will work correctly for any types that you substitute for it's generic arguments (within limitations imposed by generic constraints). Using a mechanism that internally switches on the type of the arguments runs counter to the core principle of generics - that they conform to arbitrary substitution of their type arguments.

@SLaks: I will, however, add (tongue in cheek) that it would be *wonderful* if .NET did in the future support generic constraints for constructs like operators (+,-,*,etc) so that you could more easily write generic types that could use primitive types like `int`, `long`, `decimal` in a generic manner - since the primary operations you do with such types involves the use of operators. In my experience this is one situation where type switching arises as a common (but unfortunate) solution. While there are a number other workarounds to this problem, they are all more complicated.

@Henry Jackson: An overloaded method with several parameter options *can give a compile-time error* if the situation cannot be resolved. What would you have us do in the analogous situation? Throw an exception at runtime?

How about using Polymorphism here? I can't speak to your exact situation, but typically, when you want to switch on the type of an object, that is a sign that you may want to consider a polymorphic solution.