by glyn.normington:

There are some places in the Go specification where the behaviour of closed channels
could be described more clearly.

The Channel types section says:

    A channel may be closed with the built-in function close; the multi-valued assignment form of the
    receive operator tests whether a channel has been closed.

The last statement isn't true until the channel becomes empty. If you use a multi-valued
assignment to receive from a non-empty, closed channel, you won't be able to tell the
channel has been closed (as you'll successfully receive the next value in the channel).

The Receive operator section says: 

    A receive operation on a closed channel can always proceed immediately, yielding the element
    type's zero value.

Again, this is only true of a closed, empty channel. A closed, non-empty channel will
yield the next value in the channel.

A little later, the "comma ok" form of receive is described:

    The value of ok is true if the value received was delivered by a successful send operation to
    the channel, or false if it is a zero value generated because the channel is closed and empty. 

This could perhaps mention that ok will be true in the case of a non-empty, closed
channel.

That said, the section on Close is unambiguous:

    For a channel c, the built-in function close(c) records that no more values will be sent on the
    channel. It is an error if c is a receive-only channel. Sending to or closing a closed channel
    causes a run-time panic. Closing the nil channel also causes a run-time panic. After calling
    close, and after any previously sent values have been received, receive operations will return
    the zero value for the channel's type without blocking. The multi-valued receive operation
    returns a received value along with an indication of whether the channel is closed.

So when the specification is read as whole, there isn't a problem. But perhaps the
wording of the "Channel types" and "Receive operator" sections could
be improved so as not to give the wrong impression.

(This issue was aired first here:
https://groups.google.com/forum/#!searchin/Golang-nuts/normington/golang-nuts/QjBhvNsia4I/YDDaAzNEHC4J)