FAQ
There are some places in the Go specification where the behaviour of closed
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.

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.

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.

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.

Search Discussions

  • Adonovan at Apr 14, 2014 at 2:08 pm

    On Thursday, 10 April 2014 08:43:54 UTC-4, Glyn Normington wrote:
    I'm happy to raise a bug to cover this, but thought it was worth airing
    the issue here first.
    These are all good points. (I remember the same confusion when I was
    learning Go as to whether a close() destroyed the channel or merely marked
    the last-sent value as final. The spec is perpetuating this confusion. I
    wonder if it's a relic of an earlier draft?)

    Please file a spec bug.

    cheers
    alan

    --
    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.
  • Glyn Normington at Apr 15, 2014 at 9:36 am
    Thanks Alan: https://code.google.com/p/go/issues/detail?id=7785

    Regards,
    Glyn
    On Monday, 14 April 2014 15:08:03 UTC+1, adon...@google.com wrote:
    On Thursday, 10 April 2014 08:43:54 UTC-4, Glyn Normington wrote:

    I'm happy to raise a bug to cover this, but thought it was worth airing
    the issue here first.
    These are all good points. (I remember the same confusion when I was
    learning Go as to whether a close() destroyed the channel or merely marked
    the last-sent value as final. The spec is perpetuating this confusion. I
    wonder if it's a relic of an earlier draft?)

    Please file a spec bug.

    cheers
    alan
    --
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 10, '14 at 12:43p
activeApr 15, '14 at 9:36a
posts3
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase