C# where Constraints: class, struct, new() and notnull

Every where clause is a promise the compiler enforces on your behalf — pick the promise that matches exactly what your code needs, and no more.

The previous lesson gave you the overview: constraints trade "works for absolutely anything" for real capability. Now it's time for the details — the exact syntax for each kind of where constraint, what each one specifically guarantees, how to combine several at once, and a subtler case: constraining one type parameter using another.

In this lesson, you'll go deep on where T : class, where T : struct, where T : new(), where T : BaseClass, where T : IInterface, combining multiple constraints on the same type parameter, and constraining a type parameter against another type parameter.

What Is It?

A constraint clause is written as where TParam : constraint1, constraint2, ... immediately after a generic type's or method's parameter list, before the opening { (or before the method body, if there's no other clause after it). Let's walk through each kind precisely.

Why Does It Exist?

The Problem

Different generic code needs different guarantees. A cache that must construct a fresh default instance when a key is missing needs new(). A comparer needs an interface guarantee. A type that must never accidentally hold null needs struct. One general "constraint" concept wouldn't be precise enough — real code needs several distinct, composable guarantees, each unlocking a different specific capability.

The Solution

C# provides a small, purpose-built vocabulary of constraint kinds, and lets you combine them precisely for exactly what your code needs — no more, no less. The rest of this lesson walks through each one with a concrete example of the problem it solves.

Big Picture

where T : class, IComparable<T>, new()
         ↑         ↑                  ↑
    1. class/struct/notnull   2. base class, then   3. new() —
       (if present, comes        interfaces               always last
       first)

How It Works

public bool IsNull<T>(T value) where T : class
    => value is null;

IsNull<string>(null);   //  string is a reference type
// IsNull<int>(0);      //  compile error — int is a value type, not allowed

public T? ToNullable<T>(T value) where T : struct
    => value;   // implicit conversion to T? (Nullable<T>) is always safe here

int? maybeNumber = ToNullable(42);
// ToNullable<string>("hi");   //  compile error — string is a reference type

public T CreateDefault<T>() where T : new()
    => new T();   //  compiles — guaranteed a parameterless constructor exists

public class Product
{
    public Product() { }   // has a public parameterless constructor — qualifies
}
Product p = CreateDefault<Product>();

public abstract class Shape
{
    public abstract double Area();
}

public double TotalArea<T>(IEnumerable<T> shapes) where T : Shape
    => shapes.Sum(shape => shape.Area());   //  Area() is guaranteed by the Shape constraint

public T Max<T>(T a, T b) where T : IComparable<T>
    => a.CompareTo(b) > 0 ? a : b;

public void Register<TBase, TDerived>(List<TBase> list, TDerived item)
    where TDerived : TBase
{
    list.Add(item);   //  TDerived is guaranteed assignable to TBase
}

List<Shape> shapes = [];
Register<Shape, Circle>(shapes, new Circle());   //  Circle : Shape

Simple Example

Code → Meaning → Result:

• class ensures pooled items behave as shared, mutable references — pooling a value type wouldn't make sense.
• IResettable guarantees every pooled type can be cleaned up before reuse.
• new() lets the pool manufacture a fresh instance the first time it's needed, with no items yet available.

Real-World Example

A Cache<TKey, TValue> that lazily creates a default value the first time a key is requested is a realistic use of combining notnull (a genuinely common real-world requirement for dictionary-style keys) with new() for the value type.

Notice this lesson's constraint syntax uses one where clause per type parameter, on its own — a common, very readable style once a generic type has multiple type parameters each carrying its own constraint.

Analogy

Under the Hood

Common Confusion

1. class as a constraint vs class as a declaration keyword

where T : class looks like it might mean "T must literally be the type named class" — it doesn't. In this position, class is a special keyword meaning "any reference type," not a reference to a specific class. This dual meaning (declaration keyword vs constraint keyword) trips up many learners at first.

2. notnull is weaker than it sounds

where T : notnull only prevents the type argument itself from being a nullable reference type (string?) or Nullable<T> (int?) — it's a compile-time nullability check tied to nullable reference types, not a runtime guarantee that a given value can never be null. It's commonly used for dictionary key type parameters, mirroring Dictionary<TKey, TValue>'s own constraint.

3. You cannot combine class and struct on the same type parameter

These two constraints are mutually exclusive by definition — a type cannot be both a reference type and a value type — so where T : class, struct is simply not legal syntax.

Common Mistakes

Mistake 1 — Putting new() anywhere but last

Wrong — doesn't compile:

Correct:

Mistake 2 — Expecting where T : struct to allow int?

MyMethod<int?>(...) against a where T : struct constraint fails to compile — int? (Nullable<int>) is technically a value type, but the struct constraint specifically excludes nullable value types. If you need to allow both int and int?, don't use struct — reconsider whether the constraint is really needed, or accept T? explicitly where relevant.

Mistake 3 — Reaching for a base class constraint when an interface would be more flexible

where T : Shape when all you actually need is an Area() method — this forces every future type to inherit from Shape specifically, even if it could have satisfied the need some other way. Prefer an interface constraint (where T : IHasArea) whenever you only need specific behavior, not a specific inheritance lineage — it keeps your generic code usable by a wider range of types.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've gone deep on every kind of where constraint. Let's check your understanding.

You now know every kind of generic constraint, and how to combine them precisely. Next: covariance and contravariance — how out and in let generic interfaces flex safely along inheritance hierarchies.