Closing Channels and range

## What `close` actually is `close` is a Go builtin that takes one channel argument. Calling `close(ch)` records, in the channel's runtime state, a single fact: **no further values will ever be sent on this channel**. That is all it does. It does not free memory, does not stop any goroutine, does not empty the buffer, and does not wake senders (there must not be any left — see the panics below). Because it is a statement about the channel as a whole rather than about the goroutine calling it, `close` belongs to the **sending side**. The receiving side never knows whether more values are coming; only a sender does. ## What a receiver observes There are three receive forms, and closing changes all three in the same way. **1. `v := <-ch`** — before the close, this blocks until a value arrives. After the channel is closed *and drained*, it returns the zero value of the element type immediately and never blocks again: `0` for `int`, `""` for `string`, `nil` for a pointer, slice, map or interface, and the all-zero struct for a struct type. **2. `v, ok := <-ch`** — the comma-ok form. `ok` is `true` when the value was genuinely sent by someone, and `false` when the receive completed only because the channel is closed and empty. This is the *only* way to tell a real sent zero value apart from end-of-stream. If your element type is `int` and a producer legitimately sends `0`, a bare `v := <-ch` cannot distinguish the two cases. **3. `for v := range ch`** — receives repeatedly and terminates when the channel is closed and drained. It never yields the trailing zero value; the close is the loop's exit condition, and no `break` is needed. ## Ordering: buffered values come first A common misconception is that closing discards whatever is still sitting in a buffered channel. It does not. Given `ch := make(chan string, 3)` with three values in it, closing and then receiving four times yields the three real values with `ok == true`, and only the fourth receive returns `""` with `ok == false`. The closed state becomes visible to receivers only after the buffer is empty. ## The closed state is permanent and always ready Once closed, a channel is closed forever; there is no reopen. Every subsequent receive succeeds immediately. Two consequences matter in practice: - A `select` case that receives from a closed channel is *always* ready, so a loop that keeps selecting on it will spin at full speed unless you stop selecting on that case. - Because *every* waiting receiver is released at once, closing is Go's broadcast primitive: one `close` wakes an arbitrary number of goroutines blocked on a receive, which is why cancellation is usually signalled by closing a `chan struct{}` rather than by sending a value per waiter. ## What `close` is not It is not a resource release. A channel is an ordinary garbage-collected value; nothing is freed by closing it, and nothing leaks by not closing it. It is not a flush, not a disconnect, and not an acknowledgement that receivers have finished reading — `close` returns immediately and tells you nothing about the other side. ## Who is allowed to close By convention and by compiler enforcement at the edges: the sender closes, the receiver never does. A parameter declared as a receive-only channel (`<-chan T`) cannot be closed at all — the compiler rejects it — so writing the direction into a function signature turns the convention into a checked rule. ## Typical shape A producer goroutine sends everything it has, closes the channel with `defer close(out)` or as its last statement, and the consumer drives a `for v := range out` loop that ends by itself. The producer never needs a sentinel value, and the consumer never needs a count.