What do `in` parameters and `ref readonly` parameters (C# 12) do? Explain passing large structs by readonly reference, hidden defensive copies with non-readonly structs, readonly members, when in makes code slower, the call-site rules for in and ref readonly, and how to decide between by-value, in and ref readonly.

How I would answer this in an interview

in parameters (C# 7.2) pass an argument by readonly reference: no copy, and the callee can't modify it. ref readonly parameters (C# 12) do the same but make the call-site contract stricter and clearer. Both exist mainly for large structs. The catch: with non-readonly structs, the compiler inserts hidden defensive copies, which can make in slower than passing by value. I'd explain each, readonly members, call-site rules, and how to choose.

1. Passing large structs by readonly reference

public readonly struct Matrix4x4d   // 128 bytes
{
    public readonly double M11, M12, /* ... */ M44;
    public Matrix4x4d Multiply(in Matrix4x4d other) { ... }
}

public static Vector3d Transform(in Matrix4x4d m, in Vector3d v) => ...;   // no 128-byte copy per call

Passing a 128-byte struct by value copies it on every call (and every nested call). in passes a pointer instead. Inside the method, the parameter is readonly: assignments to it or its fields don't compile.

2. Hidden defensive copies with non-readonly structs

public struct Money { public decimal Amount; public string Currency; public decimal WithGst() => Amount * 1.1m; }

static decimal Total(in Money m) => m.WithGst();   // compiler copies 'm' before calling WithGst!

The compiler must guarantee m isn't modified. WithGst() isn't marked readonly, so the compiler can't know it doesn't mutate fields — it makes a defensive copy of m and calls the method on the copy. Every member call (methods and property getters on non-readonly structs) through an in parameter may copy the whole struct — silently erasing the benefit or making it slower than by-value.

The same applies to readonly fields of struct type and ref readonly locals/returns.

3. Readonly members

Fix by marking the struct or its members readonly:

public readonly struct Money { ... }                    // all members implicitly readonly; no defensive copies

public struct Counter
{
    public int Value;
    public readonly int Doubled() => Value * 2;         // readonly member: callable without a copy
    public void Increment() => Value++;                  // mutating member
}

Auto-property getters are implicitly readonly; explicit getters aren't unless marked. Analysers (IDE0251) suggest readonly members.

4. When in makes code slower

• Small structs (≤ 16 bytes, e.g. int, Guid, DateTime, (int, int)): passing by value uses registers; in forces the value into memory and adds indirection on every access.
• Non-readonly structs: defensive copies on member calls.
• Reference types: in on a class reference is pointless (it passes a reference to a reference).
• Async/iterators/lambdas: in parameters can't be used/captured there.
• Heavy field access in loops: each access is through a pointer; the JIT may not enregister fields.

Rule of thumb: consider in/ref readonly for readonly structs larger than ~16–32 bytes on measured hot paths.

5. Call-site rules: in vs ref readonly

ref readonly was introduced for APIs that semantically need the address of a variable (e.g. MemoryMarshal/Unsafe style APIs, or methods that may return a reference derived from the argument), where silently creating a temporary would be a bug. It also lets existing ref parameters be relaxed to readonly without breaking callers that pass ref.

6. Deciding between by-value, in and ref readonly

1. Default: by value. Simple, fast for small types, works everywhere (async, lambdas).
2. in for large readonly structs passed frequently on hot paths, where benchmarks show copying costs.
3. ref readonly when the API needs a reference to an existing variable (aliasing semantics) or for interop/low-level APIs; also when converting ref APIs to read-only without breaking callers.
4. ref when the callee must mutate the caller's struct.

Always mark the struct readonly before introducing in, then benchmark.

7. A production example

A graphics/pricing engine (heavy matrix maths) passed a 128-byte Matrix struct by value through several layers; BenchmarkDotNet showed copies dominating. We added in — and performance got worse, because Matrix wasn't readonly and every method call made a defensive copy. Marking the struct readonly (it was effectively immutable already) eliminated the copies, and the hot path became ~35% faster than the original. The lesson stuck: readonly struct first, then in, then measure.