A constructor forces every caller down one fixed path. required keeps object initializers flexible, while still refusing to let anyone skip the fields that actually matter.

Object initializer syntax — new Customer { Name = "Alice", Email = "alice@example.com" } — is genuinely pleasant to read and write. You can set exactly the properties you care about, in any order, without threading them all through a constructor's parameter list. There was just one problem: nothing stopped you from forgetting one.

var customer = new CustomerDto { Name = "Alice" }; // compiles fine — Email is just... missing

If Email was supposed to be mandatory, nothing here caught that mistake. You'd either add a constructor (losing the nice named-property syntax) or find out at runtime, possibly much later, that Email was null when it never should have been.

In this lesson, you'll learn the required modifier, how it interacts with constructors and object initializers, and why it exists as an alternative — and a complement — to constructor-mandated initialization.

What Is It?

The Simple Explanation

The required modifier marks a property (or field) as something every caller must set when creating the object — using object initializer syntax — or the code simply won't compile. It's a way to keep the flexible, named, any-order style of new Thing { A = 1, B = 2 }, while still guaranteeing that certain properties are never left unset by accident.

The Technical Definition

The required modifier (C# 11) can be applied to an instance property or field that has (at minimum) an init or set accessor. When present, the compiler enforces — as a compile-time error, not a warning — that every object-creation expression for that type explicitly assigns that member via object-initializer syntax, unless the constructor being used is itself annotated with [SetsRequiredMembers] to promise the compiler it already handles the assignment internally.

Why Does It Exist?

The Problem

Before C# 11, there were exactly two ways to guarantee a property was always set, and both cost you something:

The Need

Developers needed a third option: the readability of object initializers, combined with the same enforced guarantee a constructor gives you — verified at compile time, so a missing required value is caught the moment you write the code, not discovered later.

The Solution

The required modifier:

public class CustomerDto
{
    public required string Name { get; init; }
    public required string Email { get; init; }
    public string? PhoneNumber { get; init; } // genuinely optional
}

var c1 = new CustomerDto { Name = "Alice", Email = "alice@example.com" }; //  compiles
var c2 = new CustomerDto { Name = "Bob" }; //  CS9035: required member 'Email' must be set

You keep the named, any-order initializer syntax, and the compiler now refuses to let anyone forget Email.

Big Picture

How It Works

public class Product
{
    public required string Sku { get; init; }
    public required decimal Price { get; init; }
}

var p1 = new Product { Sku = "ABC-1", Price = 19.99m }; // 
var p2 = new Product { Sku = "ABC-1" };                   //  missing required member 'Price'

public class Product
{
    public required string Sku { get; init; }
    public required decimal Price { get; init; }

    public Product() { } // still usable with an object initializer

    [SetsRequiredMembers]
    public Product(string sku, decimal price)
    {
        Sku = sku;
        Price = price;
    }
}

var p3 = new Product("ABC-1", 19.99m); //  the constructor is trusted to have set both

Simple Example

public class UserProfile
{
    public required string Username { get; init; }
    public required string Email { get; init; }
    public string? Bio { get; init; }        // truly optional
    public bool IsVerified { get; init; }     // has a sensible default (false), no need to require it
}

var profile = new UserProfile
{
    Username = "alice_codes",
    Email = "alice@example.com"
    // Bio and IsVerified are left at their defaults — that's fine, they're not required
};

// var broken = new UserProfile { Bio = "Hi there!" };
//  CS9035: Required member 'UserProfile.Username' must be set.
//  CS9035: Required member 'UserProfile.Email' must be set.

Meaning: Username and Email are non-negotiable — every single construction of UserProfile, anywhere in the codebase, is guaranteed by the compiler to have set them. Bio and IsVerified stay genuinely optional, with sensible defaults.

Real-World Example

An API layer deserializing incoming requests into a DTO is exactly where required earns its keep — it turns "the client forgot to send an ID" into a build-time guarantee for your own code, and a clear deserialization failure for missing client data:

public class CreateOrderRequest
{
    public required string CustomerId { get; init; }
    public required List<OrderLineDto> Lines { get; init; }
    public string? PromoCode { get; init; } // optional — not every order has one
}

public class OrderLineDto
{
    public required string ProductSku { get; init; }
    public required int Quantity { get; init; }
}

// Anywhere in your OWN code that builds a CreateOrderRequest, the compiler
// guarantees CustomerId and Lines are always provided:
var request = new CreateOrderRequest
{
    CustomerId = "CUST-42",
    Lines = [ new OrderLineDto { ProductSku = "SKU-1", Quantity = 2 } ]
};

// System.Text.Json also understands `required` when deserializing:
// if incoming JSON is missing "customerId" or "lines", deserialization
// throws a JsonException immediately, instead of silently leaving a null.

Notice the two layers of protection working together: required stops your own code from ever constructing an incomplete CreateOrderRequest, and the same annotation is honored by System.Text.Json, so a malformed request from an external client fails fast during deserialization instead of quietly producing an object with missing data that only breaks somewhere further downstream.

Under the Hood

Common Confusion

1. required vs a non-nullable type — related, but not the same guarantee

A non-nullable property (string Name) tells the compiler "this should never hold null" — but without required or constructor initialization, nothing actually stops you from constructing the object and leaving it unset (you just get a warning). required is what closes that gap for object-initializer construction specifically, turning "should never be null" into "genuinely cannot be skipped."

2. required doesn't replace constructors — it complements them

You can absolutely still write a full constructor for a class with required members — you just need [SetsRequiredMembers] on it if you want callers to be able to use that constructor without also supplying an object initializer. Many types offer both: a constructor for the common, positional case, and required properties so the same type also works safely with a plain object initializer.

3. required only needs set or init — not necessarily init specifically

A required property can use a regular set accessor instead of init, meaning it can still be reassigned after construction. Most designs pair required with init because they usually go together conceptually (mandatory and immutable once set) — but the two are independent features, and combining them is a choice, not a requirement of the language.

Common Mistakes

Mistake 1 — Marking everything required, even properties with sensible defaults

public class Settings
{
    public required bool DarkMode { get; init; }     // does every caller REALLY need to think about this?
    public required int RetryCount { get; init; }    // ...or is 3 a perfectly good default?
}

Reserve required for properties that genuinely have no safe default — where forcing every caller to think about the value is the correct behavior, not busywork. Give the rest a sensible default instead.

Mistake 2 — Adding a positional constructor and forgetting [SetsRequiredMembers]

public class Product
{
    public required string Sku { get; init; }

    public Product(string sku) { Sku = sku; } // missing [SetsRequiredMembers]
}

var p = new Product("ABC-1"); //  still requires an object initializer too — surprising!

Add [SetsRequiredMembers] to any constructor you want to trust as fully satisfying the required members on its own.

Mistake 3 — Assuming required validates the value, not just its presence

required only guarantees that some value was assigned — it says nothing about whether that value is meaningful. new CustomerDto { Name = "", Email = "" } compiles perfectly fine; both required members were technically "set," just to empty strings. For actual data validation (non-empty, correctly formatted, within range), you still need real validation logic — required solves "was this forgotten," not "is this correct."

When Should I Use It?

• Use required on DTOs, request models, and configuration types with several optional properties and a few genuinely mandatory ones — where a full positional constructor would be awkward, but leaving mandatory fields unenforced would be risky.
• Prefer a constructor instead when a type has few properties, all of them mandatory, and you want the strongest possible guarantee plus the ability to validate relationships between values at construction time.
• Skip required for properties that have a genuinely sensible default — forcing every caller to restate an obvious value adds noise without adding safety.

Mental Model

Key Takeaway

Check Your Understanding

You've seen how required keeps object initializers flexible while still enforcing the properties that matter. Let's check your understanding.

You now know how to keep object initializers flexible while guaranteeing the properties that genuinely can't be skipped.

dotnetmadeeasy.com — Learn C# and .NET, the right way.