# Decompiling yield return: how iterator blocks become state machines Some C# constructs compile to a single IL instruction. `yield return` compiles to an entire class. There is no "yield" opcode in the CLR, so when you write an iterator method, the compiler rewrites the whole thing into a generated type that implements `IEnumerator` and remembers where it was between calls. Understanding that rewrite explains why a decompiler sometimes shows you a cryptic `d__0` with a `switch` in it — and how a good one turns that back into the `yield return` you actually wrote. ## The method you write vs. the method that ships Here is an ordinary iterator: ```csharp public IEnumerable Evens(int max) { for (int i = 0; i <= max; i++) if (i % 2 == 0) yield return i; } ``` What ships in the assembly is almost none of that. The method `Evens` survives only as a stub that news up a generated class and returns it. The real work moves into a compiler-generated nested type — conventionally named `d__0` — that implements `IEnumerable`, `IEnumerator`, and `IDisposable`. The decompiled skeleton looks like this: ```csharp [CompilerGenerated] private sealed class d__0 : IEnumerable, IEnumerator, IDisposable { private int <>1__state; // where we are in the method private int <>2__current; // the value the last yield produced public int max; // the parameter, hoisted to a field private int 5__1; // the local 'i', hoisted to a field int IEnumerator.Current => <>2__current; bool IEnumerator.MoveNext() { /* the rewritten body — see below */ } // ... Reset/Dispose/GetEnumerator ... } ``` Two kinds of fields appear. `<>1__state` and `<>2__current` are the machinery: the state field records where to resume, and the current field holds the value `Current` returns. The others — `max` and `5__1` — are your parameter and your local `i`, **hoisted** from the stack onto the heap. They have to be fields, because a local on the stack would vanish the moment `MoveNext` returned, and the iterator needs `i` to still be there on the *next* call. ## MoveNext: a switch that resumes The body of your iterator is rewritten into `MoveNext`, structured as a dispatch on `<>1__state`. Each `yield return` becomes three steps — stash the value, record a resume state, return `true` — and the matching `case` is where the next call jumps back in: ```csharp bool IEnumerator.MoveNext() { switch (<>1__state) { case 0: // first call: start the method <>1__state = -1; 5__1 = 0; // i = 0 break; case 1: // resume point after the yield <>1__state = -1; 5__1++; // the i++ from the for-loop break; default: return false; } while (5__1 <= max) { if (5__1 % 2 == 0) { <>2__current = 5__1; // yield return i → stash value <>1__state = 1; // remember where to resume return true; // and hand control back } 5__1++; } return false; // falling off the end = yield break } ``` Read it as a resumable program. State `0` is the entry; the method runs until the first `yield return`, which sets `<>2__current`, sets the state to `1`, and returns `true`. The `foreach` consuming this iterator calls `MoveNext` again, the `switch` sees state `1` and jumps back *after* the yield to continue the loop. When the loop finally ends, `MoveNext` returns `false`, which is exactly what `yield break` (and falling off the end) compiles to — the signal to `foreach` that enumeration is over.
## How the decompiler puts yield back A decompiler reading the shipped assembly sees the generated class, not your method. Recovering the iterator is pattern recognition on a well-defined shape: 1. **Identify the state machine.** A nested `[CompilerGenerated]` type implementing `IEnumerator` with a `<>1__state` and a `<>2__current` field is the signature of an iterator block — distinct from an async state machine, which implements `IAsyncStateMachine` and is driven by awaiters rather than `MoveNext`. 2. **Un-hoist the locals.** Fields like `5__1` are mapped back to a local `i`, and fields matching the original parameters (`max`) are recognized as parameters of the reconstructed method. The `5__n` encoding makes the original identifier recoverable. 3. **Fold the switch into control flow.** Each `case` in the `MoveNext` dispatch is a resume point that corresponds to a `yield return` site. The decompiler stitches the pre-yield code and post-resume code back into one linear body, turning `<>2__current = x; <>1__state = n; return true;` back into `yield return x;` and `return false;` at the end into the implicit `yield break`. The result is your `Evens` method again — a `for` loop with a `yield return i` inside — rather than a 60-line state machine. [Glass.NET](https://delta1labs.com/products/glass) does this reconstruction by default and lets you drop to the raw `d__0` view when you want to see the actual generated machinery, which is exactly where you look when an iterator misbehaves. ## Why it is worth knowing The reconstructed `yield return` is what you want almost always, but the state machine underneath explains behaviour the high-level view hides. **Deferred execution** becomes obvious: the stub method only constructs the class, so no code in the iterator body runs until the first `MoveNext` — which is why an exception thrown "in" an iterator doesn't surface until you start enumerating. **The per-enumerator state** is visible as instance fields, explaining why two `foreach` loops over the same iterator each get their own independent walk. And when you are reading someone else's compiled library — or your own without symbols — recognizing `<...>d__` with a state/current pair tells you instantly that you are looking at an iterator, and the `case` labels in `MoveNext` map one-to-one to the `yield` points in the original. A decompiler that knows the pattern gives you the readable source; knowing the pattern yourself lets you read the machine when it matters.