How do primary constructors on classes and structs (C# 12) differ from those on records? Explain parameter capture, why parameters are not properties, the double-storage warning CS9124, mutation of captured parameters, validation, use with dependency injection, and the pitfalls you would flag in review.

How I would answer this in an interview

Primary constructors look the same on records and classes but behave very differently. On a record, record Money(decimal Amount, string Currency) generates public init properties, equality, deconstruction. On a class or struct (C# 12), class OrderService(IOrderRepository repo) just puts the parameters in scope for the whole type — no properties, no fields declared, and the compiler captures them into hidden fields only if members use them. I'd explain capture, why parameters aren't properties, CS9124 double storage, mutation, validation, DI usage and review pitfalls.

1. Records vs classes

public record Money(decimal Amount, string Currency);   // properties Amount, Currency are generated
var m = new Money(10, "AUD"); Console.WriteLine(m.Amount);

public class OrderService(IOrderRepository repo, ILogger<OrderService> logger)   // NO properties generated
{
    public Task<Order?> FindAsync(OrderId id, CancellationToken ct)
    {
        logger.LogDebug("Finding {OrderId}", id);
        return repo.FindAsync(id, ct);
    }
}
// new OrderService(repo, logger).repo  -> doesn't exist

2. Parameter capture

When a class member references a primary constructor parameter, the compiler generates a private field (with an unspeakable name) and rewrites references to use it. If parameters are only used in field/property initialisers, no capture field is generated — the value is used during construction only.

public class RateLimiter(int limit)
{
    private readonly SemaphoreSlim _gate = new(limit);   // used in initialiser only -> not captured
}

3. Why parameters aren't properties

The C# team deliberately didn't auto-generate properties for classes: classes are often services or entities where you don't want every constructor input to become public API. Parameters are implementation details in scope. If you want a property, declare it explicitly:

public class Customer(string name)
{
    public string Name { get; } = name;   // explicit property initialised from the parameter
}

4. Double storage — warning CS9124

public class Customer(string name)
{
    public string Name { get; } = name;        // stored in the property's backing field
    public string Greeting() => $"Hi {name}";  // captures 'name' AGAIN in a hidden field
}

Now there are two copies: Name's backing field and the captured parameter. If one changes (e.g. Name becomes settable and is updated), they diverge — Greeting() uses the old value. The compiler warns (CS9124: parameter is captured into the state of the enclosing type and its value is also used to initialise a field, property or event). Fix: use Name in members, not name.

5. Mutation of captured parameters

Captured parameters are mutable (no readonly):

public class Counter(int start)
{
    public int Next() => ++start;   // legal - mutates the hidden field
}

That's surprising for DI services where you'd expect dependencies to be readonly; nothing stops repo = null!; inside a method. Teams that care declare explicit private readonly fields initialised from parameters, or rely on an analyser rule.

6. Validation

There's no constructor body to put guard clauses in. Options:

public sealed class Pager(int pageSize)
{
    private readonly int _pageSize = pageSize is > 0 and <= 100
        ? pageSize
        : throw new ArgumentOutOfRangeException(nameof(pageSize));
}

public sealed class EmailSender(SmtpOptions options)
{
    private readonly SmtpOptions _options = options ?? throw new ArgumentNullException(nameof(options));
}

Or add an explicit constructor that chains to the primary constructor (public Pager() : this(20) { }) — but validation logic itself must live in initialisers. If validation is complex, use a normal constructor.

7. Use with dependency injection

Primary constructors are great for DI services: less boilerplate, dependencies visible in the declaration. The DI container calls the primary constructor like any other. Caveats: captured dependencies are mutable fields; with multiple constructors, the primary constructor must be called by others via this(...).

8. Pitfalls I flag in review

• CS9124 double storage (parameter used in members and in an initialiser).
• Capturing parameters intended as construction-only (e.g. a large config object) — they live as long as the object.
• Mutating captured parameters.
• Missing validation for value parameters (no guard clauses).
• Primary constructors on entities with validation needs or EF Core requirements (EF needs a usable constructor; parameter names must match properties for constructor binding).
• Confusing records and classes (expecting obj.Param to exist).
• Naming: parameters are camelCase but used like fields in members — some teams prefer _-prefixed explicit fields for clarity.

9. A production example

After converting services to primary constructors, a bug appeared: a service exposed public IClock Clock { get; } = clock; for tests and used clock internally. A test replaced Clock via reflection/mocking frameworks, but internal methods still used the captured clock — tests passed while production behaviour differed. CS9124 had been flagged as a warning and ignored. We made CS9124 an error and standardised on using either the parameter or an explicit readonly field, never both.