Explain ref locals, ref returns and ref fields in C#. How do ref safety rules and the scoped keyword work, what does CollectionsMarshal.GetValueRefOrAddDefault give you, when do ref returns improve performance, and what bugs can references to storage cause?

How I would answer this in an interview

Ref locals and ref returns let you hold and return references to storage (array elements, fields, dictionary values) instead of copies; ref fields (C# 11) let a ref struct store such a reference, which is how Span<T> is built. The compiler's ref safety rules guarantee references never outlive what they point to, with scoped to narrow lifetimes. I'd cover each, CollectionsMarshal.GetValueRefOrAddDefault, when ref returns help performance, and the bugs references to storage can cause.

1. Ref locals and ref returns

public struct Pixel { public byte R, G, B, A; }

public sealed class Image(int width, int height)
{
    private readonly Pixel[] _pixels = new Pixel[width * height];
    public ref Pixel At(int x, int y) => ref _pixels[y * width + x];   // ref return
}

ref Pixel p = ref image.At(10, 20);   // ref local: alias for the array element
p.R = 255;                            // modifies the element in place - no copy
image.At(11, 20).G = 128;             // direct in-place update

Without ref, At would return a copy of the struct, and mutations would be lost. ref readonly returns expose without copying and without allowing writes:

public ref readonly Matrix4x4 Transform => ref _transform;   // no 64-byte copy per access

2. Ref fields (C# 11)

public readonly ref struct Window<T>
{
    private readonly ref T _start;
    private readonly int _length;
    public Window(ref T start, int length) { _start = ref start; _length = length; }
    public ref T this[int i] => ref Unsafe.Add(ref _start, (uint)i < (uint)_length ? i : throw new IndexOutOfRangeException());
}

Only ref structs can have ref fields (they must stay on the stack). This made Span<T> expressible in C# rather than relying on runtime magic.

3. Ref safety rules and scoped

The compiler tracks, for each reference and ref struct value, its safe context: whether it may refer to the current method's stack (function-member scope) or can escape to the caller (caller-context).

• You can't return a ref to a local variable (return ref local; → CS8168) or to a span over stackalloc.
• You can return refs to fields of heap objects, array elements, static fields, and ref parameters (they come from the caller).
• scoped (C# 11) marks a parameter or local as not escaping the method:

public static int Sum(scoped ReadOnlySpan<int> values) { ... }   // promises not to store/return 'values'

Callers can then pass spans over stack memory, and the method can't leak them. It also relaxes rules for ref struct methods (e.g. Span<T> parameters of ref struct methods default to scoped in some positions).

• [UnscopedRef] (C# 11) does the opposite for specific cases (e.g. returning a ref to a field of this in a struct).

4. CollectionsMarshal.GetValueRefOrAddDefault

var counts = new Dictionary<string, int>(StringComparer.Ordinal);
foreach (var word in words)
{
    ref int count = ref CollectionsMarshal.GetValueRefOrAddDefault(counts, word, out _);
    count++;                                         // ONE hash lookup, in-place update
}

• Returns a ref to the value slot, adding a default entry if missing.
• Avoids the double lookup of TryGetValue + indexer set, and avoids copying large struct values.
• GetValueRefOrNullRef returns a null ref for missing keys (check with Unsafe.IsNullRef).
• The ref is valid only until the dictionary is modified (adds/removes can resize and move entries).

5. When ref returns improve performance

• Large structs stored in arrays/collections (matrices, game entities, pixels) — avoid copying on each access and allow in-place mutation.
• Hot paths in data structures: custom collections returning refs (ref T this[int i]), ECS-style component storage.
• Dictionary counters/accumulators with GetValueRefOrAddDefault.
• Spans and parsers: MemoryMarshal.GetReference(span) + Unsafe.Add in low-level loops (careful!).

For small types (≤ 16 bytes) or reference types, copying is cheap and refs add complexity for little gain. Measure with BenchmarkDotNet.

6. Bugs references to storage can cause

• Stale refs after resize: a ref into a List<T> backing array (via CollectionsMarshal.AsSpan) or a dictionary entry becomes stale when the collection grows; writes go to the old array and are lost.
• Aliasing: two refs to the same storage; modifying through one changes what the other sees — surprising in algorithms that assume independence.
• Exposing internal state: a public ref return lets callers mutate private storage, bypassing invariants (use ref readonly).
• Ref to readonly fields of structs may be defensive copies when not marked ref readonly.
• Thread safety: refs to shared storage mutated concurrently cause races (no locks are implied).
• Unsafe helpers (Unsafe.Add, Unsafe.As) bypass bounds and type checks — memory corruption if misused.

7. A production example

A simulation service updated millions of Particle structs (48 bytes each) per frame via particles[i] = particles[i] with { ... } — copying each struct twice. Changing the loop to ref var p = ref particles[i]; p.X += p.Vx * dt; (and later iterating a Span<Particle>) removed the copies and roughly doubled frame throughput. Separately, a word-count job switched to GetValueRefOrAddDefault, halving hash lookups. One regression: a helper cached a ref to a List<T> element across an Add that resized the list — a test with a small initial capacity caught it.