Why can a `chan int` be assigned to a `<-chan int` variable, but never the reverse?

## Direction is part of the type Go has three channel types over any element type `T`: - `chan T` — bidirectional: you may send, receive and close. - `<-chan T` — receive-only: you may receive and range; you may not send or close. - `chan<- T` — send-only: you may send and close; you may not receive. The arrow is part of the *type*, not a property of the channel object. `make` only ever produces a bidirectional channel; the directional types exist so a function signature can hand out a narrowed view. ### The assignability rule A value of channel type `V` is assignable to channel type `T` when: `V` and `T` have identical element types, **`V` is a bidirectional channel**, and at least one of `V` or `T` is not a named type. Read the three parts: - *Identical element types.* `chan int` never assigns to `<-chan int64`; there is no element conversion. - *`V` is bidirectional.* This is the asymmetry. You can hand over less than you hold, never more. - *At least one unnamed.* `<-chan int` and `chan<- int` are type literals, so unnamed; the clause is satisfied automatically in the common case. It only bites if you define types on both sides, e.g. `type Events chan int` and `type Feed <-chan int` — two named types, so `var f Feed = someEvents` is rejected even though the direction is being narrowed. ```go ch := make(chan int, 1) var recv <-chan int = ch var send chan<- int = ch ``` Both of those compile. `var both chan int = recv` does not. ### Why a conversion cannot widen it back A natural next move is to force it: `(chan int)(recv)`. That fails too. Conversions are permitted when the value is already assignable, or when the two types have identical underlying types — and for channel types the spec adds the same directional requirement, that the source be bidirectional. So the narrowing is one-way for both relations. This is unusual for Go: conversion is normally the escape hatch that gets you past assignability, and channel direction is one of the few places where it deliberately does not. The two directional types are also not related to each other. `<-chan int` and `chan<- int` neither assign nor convert in either direction; both would have to go back through a bidirectional value you no longer have. ### What the restriction buys you It makes channel ownership expressible in a signature. The convention in Go is that **the sender closes**, and a receive-only return type makes that convention checkable: ```go func parse(lines []string) <-chan Record { out := make(chan Record) go func() { defer close(out) for _, l := range lines { out <- parseLine(l) } }() return out } ``` Inside `parse`, `out` is a `chan Record`, so the goroutine can send and close. The caller receives a `<-chan Record`, and `close(c)` on it is a compile-time error, as is a send. A whole class of "who closes this?" bugs is removed statically, at zero run-time cost, purely by the return type. The same applies to parameters: a worker that only consumes takes `<-chan Job`, and a function that only produces takes `chan<- Result`. Readers learn the data-flow direction from the signature without reading the body. ### What is *not* restricted Everything else about the channel still works through a directional view. `len` and `cap` are legal on both directional types. A receive-only channel can be ranged over, and the `v, ok := <-c` form works, with `ok` reporting false once the channel is closed and drained. `select` cases are checked against the direction: a receive case on a `chan<- T` is a compile error, and a send case on a `<-chan T` is too. And because direction is static, there is no run-time representation of it: passing a channel through a directional variable creates no wrapper, no copy of the buffer, and no indirection. The value is the same channel pointer either way, and the same channel can be viewed as receive-only by one goroutine and send-only by another at the same time. ### The one escape, and why not to take it You can defeat the restriction with `unsafe`, and people occasionally do it in tests. Do not: the moment a consumer can close a channel the producer is still writing to, you have converted a compile-time guarantee into a send-on-closed-channel panic in production. If you find yourself needing the bidirectional value back, the real fix is to keep it where it was created and hand out narrowed views from there.