On Wed, Jan 24, 2018 at 8:59 PM, dc0d <kaveh.shahbaz...@gmail.com> wrote:
> It is as described in the spec. Regarding the specs it's correct. But > that's not the reason. > You didn't ask for a reason this time, you ask for what is happening. > The original question is about the "why". > > Why is that so? This behavior was unexpected. > And it was explained to you, repeatedly. Maybe you could try and explain why the explanations given to you aren't sufficient? Like, you got * Evaluating the RHS only after the communication can succeed will forcibly create an intolerable contention on the communication * The evaluation order becomes predictable independently of the actual value of the LHS * It is easier to spec the evaluation order and the effect of sending on a nil-channel separately, than mingling them * Whatever, some decision had to be made, this seemed as good as any and probably a couple' more at this point. In particular that first one seems like very compelling reason not to do what you apparently expected. At this point, you should explain a) why are these not enough and b) why does it actually *matter*? Like, say for the sake of argument that there literally was no reason. Someone flipped a couple of coins and the current spec came out of those coin flips. What does that change? > > > On Wednesday, January 24, 2018 at 11:20:01 PM UTC+3:30, Axel Wagner wrote: >> >> Both the channel and the value expression are evaluated before >>> communication begins. Communication blocks until the send can proceed. A >>> send on an unbuffered channel can proceed if a receiver is ready. A send on >>> a buffered channel can proceed if there is room in the buffer. A send on a >>> closed channel proceeds by causing a run-time panic. A send on a nil >>> channel blocks forever. >> >> >> https://golang.org/ref/spec#Send_statements >> >> So, yes. >> >> On Wed, Jan 24, 2018 at 8:43 PM, dc0d <kaveh.sh...@gmail.com> wrote: >> >>> If the channel is nil, there's nothing to lock. But also, there's no >>>> sending happening. >>>> >>> >>> So first the payload is computed and then the nil check happens? >>> >>> -- >>> 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...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
