No such thing as a 'nil channel'. You are merely setting a variable to nil, regardless what the previous content is.
It's just that Go allows you to receive from a nil variable if that variable's type is a channel, in which case it blocks forever. On Sunday, September 1, 2019 at 9:03:58 AM UTC-7, clement auger wrote: > > hi, > > I am looking for further details and explanations about the various > behaviors > associated with closed Vs nil channels. > > I already read > https://stackoverflow.com/questions/43616434/closed-channel-vs-nil-channel > and other publications such as > > https://medium.com/justforfunc/why-are-there-nil-channels-in-go-9877cc0b2308 > (for example) > > They repeat the explanation of the behaviors the programmer will have to > deal with, > however they don't really explain the internal, nor the reasons of the > differences > found with this example https://play.golang.org/p/4LuZ32gzWbu when > closing or niling the channel > > I wonder under which case it is useful to panic on write, Vs branching to > a default case within a select. > Said differently what is the advantage of a panic Vs a syntax like ok := > mychan <- myval; if !ok { return "not wrote" } > > This happened while reading at T.L. in > https://groups.google.com/forum/#!topic/golang-nuts/lEKehHH7kZY > > *Yes, there are ways to handle the problem of uncertain number of senders, > but there are no simple ways.* > *A mechanism must be designed to avoid any sender writing to a closed > channel.* > > thanks for anyone able to provide some details. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/758e9c07-648f-4d29-8035-37e1e0d1dba4%40googlegroups.com.
