c# generic in parameter: Practical Usage and Code Examples

When you write a method that should work with multiple types without duplicating logic, a generic type parameter lets you defer the concrete type to the call site. The C# generic in parameter syntax is straightforward, but constraints and inference rules determine how far you can push it. This article covers the syntax, constraint system, runtime behavior, and common pitfalls so you can decide when a generic method is the right tool.

Declaring a Generic Method

A generic method declares one or more type parameters after the method name, before the parameter list. The type parameter acts as a placeholder for the actual type supplied by the caller.

public static T Max<T>(T left, T right)
{
    return Comparer<T>.Default.Compare(left, right) >= 0 ? left : right;
}

Here T appears in the return type and in both parameters. The method can be called with any type that implements IComparable<T>, but the compiler does not know that yet. Without a constraint, the only operations available on T are those defined on object, such as ToString() or GetHashCode(). The Comparer<T>.Default call works because Comparer<T> internally checks for IComparable<T> and falls back to IComparable if needed, but that is a runtime detail.

To use operators like + or - on T, you need a different approach because C# does not allow operator constraints. You would either use an interface like INumber<T> in .NET 7+ or provide a delegate that performs the operation.

Adding Constraints to Type Parameters

Constraints tell the compiler what capabilities a type argument must have. They appear in a where clause after the parameter list.

public static T Max<T>(T left, T right) where T : IComparable<T>
{
    return left.CompareTo(right) >= 0 ? left : right;
}

Now the compiler knows T has a CompareTo method, so the implementation is direct and type-safe. Common constraints include:

where T : class – reference type
where T : struct – value type
where T : new() – parameterless constructor
where T : BaseClass – inherits from a specific base
where T : IInterface – implements an interface
where T : U – type argument must be or derive from another type parameter

You can combine multiple constraints, but only one base class and one new() are allowed. The struct constraint implicitly gives a parameterless constructor, so you cannot combine struct with new().

Constraints also affect how the method body behaves. With where T : class, you can compare to null; with where T : struct, default(T) is a value with all zero bits. The new() constraint allows new T(), which is useful for factory-style methods.

Multiple Type Parameters and Relationships

Methods often need more than one type parameter. The same rules apply, but constraints can reference other parameters.

public static Dictionary<TKey, TValue> CreateLookup<TKey, TValue>(
    IEnumerable<TKey> keys,
    Func<TKey, TValue> valueFactory) where TKey : notnull
{
    var result = new Dictionary<TKey, TValue>();
    foreach (var key in keys)
    {
        result[key] = valueFactory(key);
    }
    return result;
}

The notnull constraint is available in C# 8+ and prevents nullable reference types from being used as dictionary keys. It also ensures the key is never null at runtime.

When one type parameter is constrained by another, the relationship is explicit:

public static void Copy<TInput, TOutput>(TInput source, TOutput target)
    where TInput : IEnumerable<TOutput>
{
    foreach (var item in source)
    {
        // target must be able to accept TOutput
    }
}

This guarantees that the input can be enumerated as TOutput, which is useful for generic conversion helpers.

Type Inference and Explicit Specification

The compiler can often infer type arguments from the method arguments, so you do not have to write them explicitly.

var max = Max(3, 7);          // T is int
var maxString = Max("a", "b"); // T is string

Inference works from the parameters, not from the return type. If a type parameter appears only in the return type, you must specify it explicitly:

public static T DefaultValue<T>() => default;

// Compiler error: cannot infer T
// var value = DefaultValue();

// Must specify
var value = DefaultValue<int>();

Inference also fails when the arguments are of different types and no common type can be found. For example, Max(1, 2.0) cannot infer T because int and double have no implicit common type. You can explicitly specify Max<double>(1, 2.0) to force a conversion, but the method will receive 1 as a double.

When inference succeeds, the compiler also checks that the inferred type satisfies all constraints. If not, you get a compile-time error rather than a runtime failure.

Performance and Runtime Behavior

Generic methods are reified at runtime. For value types, each distinct type argument gets its own specialized method implementation, so there is no boxing when you pass an int or a struct. This is one of the main performance advantages over using object parameters.

For reference types, the runtime shares a single implementation because all references have the same representation. This means a generic method with a string and a Stream uses the same JIT-compiled code, but the type checks are still static.

Constraints do not add runtime overhead; they are resolved at compile time. The JIT may generate different code for value types to avoid boxing and virtual dispatch, but you do not control that directly. If you need to avoid the cost of interface calls inside a generic method, you can sometimes use a delegate or a strategy pattern, but that is a design tradeoff, not a generic-specific issue.

One subtle runtime detail: static fields in a generic class are per constructed type. For a generic method that is not inside a generic class, there are no static fields tied to the type parameter, but if the method is in a generic class, each closed type gets its own static state.

Common Pitfalls and Edge Cases

A common mistake is assuming that default(T) is always null. For value types, it is a zero-initialized struct. For nullable value types, it is null in the nullable sense. Use EqualityComparer<T>.Default when you need to compare values without knowing whether they are reference or value types.

Another pitfall is covariance and contravariance. Generic type parameters in methods are invariant by default. You cannot pass a List<string> to a method expecting IEnumerable<object> unless the method declares out or in modifiers on the interface, not on the method itself. Generic method type parameters cannot be marked out or in; variance only applies to interfaces and delegates.

Nullability also interacts with constraints. In a nullable-enabled context, where T : class allows T to be a nullable reference type unless you add where T : notnull. Conversely, where T : struct makes T non-nullable. The notnull constraint is the safest way to ensure a type argument is never null.

Finally, be careful with new() when the type argument is a reference type that has a parameterless constructor. The constraint guarantees the constructor exists, but it does not guarantee the constructor is public. It must be public and parameterless. If you need to create instances with arguments, use a factory delegate instead.

When to Use Generic Parameters vs. Other Options

Generic methods are not always the best choice. If you only need to pass a value and call a few predefined operations, an interface or a delegate may be simpler. For example, a method that sorts a list can accept IComparer<T> rather than being generic itself.

Use a generic parameter when:

You need to preserve the concrete type across the method boundary, such as returning the same type as the input.
You want to avoid boxing for value types in performance-sensitive code.
You need to enforce compile-time relationships between parameters, such as one type being an enumerable of another.

Avoid generics when the method body would need to use reflection to work with the type. Reflection defeats the purpose of static type safety and often costs more than a non-generic approach. Also avoid generics when the set of supported types is small and known; a simple overload set may be more readable.

A generic method with too many constraints becomes hard to use. If callers must jump through hoops to satisfy the constraints, consider whether an interface or a base class would be more pragmatic. The goal is to make the method flexible without pushing complexity onto every call site.