Nil Channels and Directional Types

## The zero value of a channel A channel is a reference type. `var ch chan int` declares a channel variable and initialises it to its zero value, `nil`. Only `make(chan int)` or `make(chan int, n)` allocates the runtime channel that a nil channel variable does not point to. The language then defines, plainly: - A **send** on a nil channel blocks forever. - A **receive** from a nil channel blocks forever. - `close` on a nil channel **panics**. No error, no panic and no zero value comes back from the first two. The goroutine parks and is never rescheduled. ## Why blocking rather than panicking The reason is mechanical rather than philosophical. A goroutine blocked on a channel is placed on that channel's wait queue; it is woken when another goroutine performs the matching operation on **the same channel**. With a nil channel there is no channel object and therefore no queue to be placed on and no handle any other goroutine could name in order to wake it. Blocking forever is the honest description of a wait that nothing can satisfy. The contrast with a legitimate blocked receive matters. `<-make(chan int)` also blocks right now, but it is blocked on a real object that another goroutine can send to or close. A nil-channel wait has no such escape. ## How you meet it by accident The overwhelmingly common cause is a channel that was declared but never made: - A struct field of channel type populated by a struct literal that skipped the constructor. - A package-level `var done chan struct{}` where the `make` lives in an `init` path that did not run. - A channel returned from a function that took an early error return and returned the zero value. The symptom is not a crash at the point of the mistake. It is a goroutine that silently stops making progress at the first send or receive. In a program that is otherwise idle, the runtime notices that no goroutine can ever run again and aborts with `fatal error: all goroutines are asleep - deadlock!`. In a busy server other goroutines are still runnable, so the process keeps serving and the stuck goroutine just accumulates, which is why this often surfaces as a slow leak rather than a crash. ## Reading it in a goroutine dump When the runtime dumps goroutines, each status line names what the goroutine is parked on. A nil-channel wait is spelled out explicitly: ```text goroutine 6 [chan receive (nil chan)]: goroutine 7 [chan send (nil chan)]: ``` That parenthesised `(nil chan)` is the direct clue: it is not a slow producer or a full buffer, the channel value itself is nil. Seeing it, you look for the missing `make`, not for a missing sender. ## The useful half Because a nil channel is never ready, a `select` case whose channel expression evaluates to nil can never be chosen. Assigning nil to the variable a case reads therefore switches that case off for as long as the variable stays nil, and assigning a real channel back switches it on again. That is the standard way to retire a source that has finished without restructuring the loop — a deliberate use of exactly the behaviour that bites people by accident. The caution that goes with it: if *every* case in a `select` is nil and there is no `default`, the `select` can never proceed, and the goroutine is parked as surely as on a bare nil receive. ## Close is the exception `close(ch)` on a nil channel panics with `close of nil channel`. It is worth remembering as a pair with the blocking rules, because it breaks the pattern: two of the three nil-channel operations block and the third crashes. Guarding with `if ch != nil { close(ch) }` is legal but usually a sign that ownership of the channel is unclear. ## What a good answer includes State the rule for both directions, name the zero value as the reason a nil channel shows up at all, note the panic on close, and mention that the blocking behaviour is deliberately exploited to disable a `select` case rather than being purely a hazard.