Your iter.Seq2 file iterator opens a file it reads from; how do you guarantee it closes when the caller breaks early?

## The scope that matches the loop A push iterator has two functions in it: the factory that builds the sequence, and the closure the factory returns. They have completely different lifetimes. ``` func Lines(path string) iter.Seq2[string, error] { // returns instantly return func(yield func(string, error) bool) { // runs for the whole loop ... } } ``` The factory returns before the caller has even started ranging. The closure runs from the first element to the last. So the closure's frame is the only scope in the whole design whose lifetime is "the duration of the loop", and that is where a resource the loop needs must be acquired and deferred. ``` return func(yield func(string, error) bool) { f, err := os.Open(path) if err != nil { yield("", err) return } defer f.Close() ... } ``` Opening in the factory instead has two defects. The file opens as a side effect of merely constructing the sequence, even if nobody ranges it, which breaks the laziness callers assume. And there is nothing to defer against: the factory returns immediately, so a `defer` there would close the file before the first element is ever produced. ## Why break does not skip the cleanup The worry people have is that the caller's `break` somehow abandons the iterator mid-flight, the way abandoning a generator would in some languages. It does not, provided your iterator honours the protocol. Walk the three exits: **Exhaustion.** Your production loop ends, the closure returns normally, the deferred Close runs. Unremarkable. **`break` (or the loop body finishing early any other way).** The generated `yield` returns false. Your `if !yield(...) { return }` guard returns. The frame unwinds and the deferred Close runs. Note that this only works because you checked the bool: an iterator that ignores it does not return at that point, and its cleanup is delayed until it has finished producing values nobody will read. **A non-local exit or a panic in the loop body.** If the caller `return`s out of the enclosing function from inside the loop, or the body panics, the runtime unwinds the loop body *through* the iterator's frame. Deferred calls in the iterator run as part of that unwinding. So `defer f.Close()` inside the closure is a genuine guarantee across all three exits, and it runs exactly once because a frame unwinds once. That is the property worth stating in an interview: in a push iterator, `defer` inside the returned closure is a real cleanup guarantee, not a best-effort one — as long as you return when yield says false. ## The per-element trap One open resource for the whole loop is easy. The mistake is per-element: ``` for _, e := range entries { f, err := os.Open(e) ... defer f.Close() // WRONG: one live handle per entry if !yield(read(f)) { return } } ``` Every deferred Close is registered against the *closure's* frame, which does not return until the entire walk ends. On a tree of ten thousand files you exhaust the process's file descriptors long before the loop finishes. The fixes are the ordinary ones: close explicitly before moving on, or move the per-element work into its own small function so its `defer` fires per call, or restructure so the value you yield does not need the handle any more. The third option is a design decision rather than a fix: yield the open `*os.File` itself and document that the caller owns closing it. That can be the right API for a library whose whole job is handing out readers, but it is a promise you are making to every importer, and it fails badly if a caller breaks out of the loop holding one. ## Proving it Assertion is not enough here, because the bug only appears for callers who stop early — the exact case nobody exercises by accident. The test is small: 1. Build the sequence over a fixture with several entries. 2. Range over it and `break` on the second element. 3. Assert that the release ran, that it ran exactly once, and that the counter does not move afterwards. Counting releases matters as much as observing one: an iterator that closes in both a `defer` and an explicit path double-closes, and a double `Close` on a file returns an error most code discards. Adding a second case that returns out of the enclosing function from inside the loop covers the non-local exit. ## The review checklist For any hand-written push iterator that touches a resource, four questions: is the resource acquired inside the returned closure rather than the factory; is its release deferred there; is every `yield` result checked so the return actually happens; and is anything deferred inside the production loop rather than around it. Those four catch the leaks. The fifth question is the design one — if a per-element resource escapes to the caller, is that written down in the doc comment.