The compiler will produce the same result using an uninitialized channel variable (ie nil chan); btw, the spec admits that a "nil channel" is a valid concept, several references can be found within it.
You might as well quote the specification rather than rephrasing, it is way shorter and efficient. https://golang.org/ref/spec#Send_statements "A send on a nil channel blocks forever. " Le dimanche 1 septembre 2019 19:55:13 UTC+2, Albert Tedja a écrit : > > 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/4f6709af-1d6c-40b2-b008-b0dad4ff7db3%40googlegroups.com.
