Directional Channels and Iteration

A pipeline stage is written as func square(in chan int, out chan int). The signature says callers may send into in, receive from in, send into out, receive from out — everything. Nothing stops a caller from closing in mid-stream, squaring nothing, or from receiving out of out and stealing results meant for the next stage. The bug is not a runtime condition you can test for; the type simply does not record who is allowed to do what.

Directional channel types fix this at compile time:

func square(in <-chan int, out chan<- int) {
	for n := range in {
		out <- n * n
	}
}

func generate(nums ...int) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for _, n := range nums {
			out <- n
		}
	}()
	return out
}

func main() {
	square(generate(2, 3, 4), results) // last arg must be chan int or chan<- int
}

The arrow now sits on one side of the type:

<-chan int puts the arrow before the type — receive-shaped: data comes out toward you. chan<- int puts it after — send-shaped: data goes in through you. In square, in is receive-only because the stage's job is to read; out is send-only because its job is to write. A caller looking at the signature can now answer both ownership questions without reading the body: who closes what, and where do results flow.

The constraint that makes this practical: a bidirectional channel converts to a directional one, never the reverse. var c chan int; var s chan<- int = c compiles; var c2 chan int = s does not. Widening to a restricted view is safe — you promised less than you have — while narrowing would hand out permissions the original holder never granted. Inside the function, you also cannot undo the restriction: square cannot smuggle in back out as a chan int for someone else to send on.

The safety net people notice last but appreciate most: close requires a bidirectional or send-only channel. You can close a chan<- int — the producer closes its own output, exactly as every pipeline example has done. You cannot close <-chan int, so a consumer that receives from in cannot terminate the producer's stream by fiat. The compile error enforces the ownership rule from Closing Channels instead of trusting review discipline.

Three stages, each a plain function, composed by calling them the way you would compose pure functions — except every stage runs concurrently because each owns a goroutine:

func generate(nums ...int) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for _, n := range nums {
			out <- n
		}
	}()
	return out
}

func square(in <-chan int) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for n := range in {
			out <- n * n
		}
	}()
	return out
}

func sum(in <-chan int) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		total := 0
		for n := range in {
			total += n
		}
		out <- total
	}()
	return out
}

func main() {
	for v := range sum(square(generate(2, 3, 4))) {
		fmt.Println(v) // 29
	}
}

Read the signatures alone and the program's shape is complete: generate only produces, square reads then produces, sum reads and emits one final answer. Each stage closes its own output when its input range ends, so termination flows backward through the chain automatically — generate finishes and closes, square's range ends and closes, sum follows. One range in main drains the whole pipeline. No shared state, no WaitGroup, no explicit handshaking between stages; the directional types plus range and close carry all of it.

This composition also exposes the cost model that decides when pipelines are the right shape. Every stage is a goroutine and an unbuffered channel, so backpressure propagates: sum blocks on its final send until main receives, which blocks square, which blocks generate. Stages advance in lockstep — throughput is set by the slowest stage, and nothing queues unboundedly. For CPU-shaped transformations of large streams that is exactly the desired behavior, and it is the design that Fan-Out and Fan-In later parallelizes by giving one stage multiple workers.

Where the pattern bends: stateful stages (sum above) cannot be duplicated naively — two sums would emit two partial totals nobody merges. And error propagation does not exist yet — a stage that fails has no channel to report on, so production pipelines wrap stages in errgroup or carry a result struct instead of a bare int. Directional types get the architecture right; error and cancellation channels are the layers built on top in phase 480.

Directional types are compile-time ownership. The same channel variables, reassignable to nil at runtime, give select a switch — a case that can be turned off while the program runs.

func merge(primary, backup <-chan int, done <-chan struct{}) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		var secondary <-chan int = backup
		for {
			select {
			case v := <-primary:
				out <- v
			case v := <-secondary:
				out <- v
			case <-done:
				return
			}
		}
	}()
	return out
}

While secondary holds the backup channel, both inputs compete. If backup fails and the goroutine assigns secondary = nil, that case becomes permanently unready — select behaves as though the line were deleted — without restructuring the loop or adding an if useBackup guard around every receive. The type of secondary must be receive-only (<-chan int) precisely so that nil-assignment and channel-assignment are the only operations ever applied to it; the pattern and the directional type reinforce each other.

Three rules keep the trick from becoming a footgun:

• A select whose every case is nil with no default blocks forever. Disabling branches is only safe while at least one live path remains. The merge loop above keeps primary and done — turn those off too and the goroutine parks permanently, the leak class from Goroutine Leaks.
• Readability cost is real. secondary starts as an optional input; if a reader must trace assignments across a hundred lines to learn which cases are live, a plain if is kinder. Reserve nil-switching for selects where branches genuinely change at runtime — failover inputs, pause/resume on a control channel, optional replication streams.
• nil means disabled, closed means done — do not blur them. Assigning nil to a work channel says stop listening, this source is off; closing says the stream has ended and remaining values still count. The first is a mutable condition, the second a permanent fact on the channel itself.

The larger design lesson: a channel's type encodes a permanent permission (send-only, receive-only), while a channel variable's value encodes a temporary state (live, nil, closed — three states select already understands). API design with directional types uses the first; control logic inside a goroutine uses the second. Keeping both visible in the signature — <-chan parameters, a separate done <-chan struct{} — is what makes concurrent functions readable at a glance, and it is the discipline every pattern in the next phase (worker pools, fan-out, errgroup) inherits.