channels could be described more clearly.
The Channel types <http://golang.org/ref/spec#Channel_types> section says:
A channel may be closed with the built-in function close<http://golang.org/ref/spec#Close>;
the multi-valued assignment form of the receive operator<http://golang.org/ref/spec#Receive_operator> tests
whether a channel has been closed.
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 <http://golang.org/ref/spec#Receive_operator> section
says:
A receive operation on a closed <http://golang.org/ref/spec#Close> channel
can always proceed immediately, yielding the element type's zero value<http://golang.org/ref/spec#The_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.
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 <http://golang.org/ref/spec#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<http://golang.org/ref/spec#Run_time_panics>.
Closing the nil channel also causes a run-time panic<http://golang.org/ref/spec#Run_time_panics>.
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<http://golang.org/ref/spec#Receive_operator> returns
a received value along with an indication of whether the channel is closed.
channel. Sending to or closing a closed channel causes a run-time panic<http://golang.org/ref/spec#Run_time_panics>.
Closing the nil channel also causes a run-time panic<http://golang.org/ref/spec#Run_time_panics>.
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<http://golang.org/ref/spec#Receive_operator> 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.
I'm happy to raise a bug to cover this, but thought it was worth airing the
issue here first.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
