On Sun, Dec 31, 2017 at 12:48 PM dc0d <kaveh.shahbaz...@gmail.com> wrote:
> Indeed everything works according to the specs. That is what is being questioned (the specs). Well, questioning the specification and expecting unspecified behavior seems like two different things. > This behavior for case clause of select statements have different semantics than case clause of switch statement. > > While the latter gets evaluated lazily (short circuited), the former gets evaluated eagerly - inconsistent semantics for looking-the-same syntax. I disagree. A && B does not look-the-same to me compared to A <- B. Actually, I see nothing in common. One is an expression, the other is a statement, etc. > Here all the values will get prepared first, whether or not they are going to be used. And only after this step, the select statement would check if a channel is nil or not. That's a fundamentally important property of the select statement. > While it should be other way around. First the select statement should check if a participant channel is nil. And only when a channel is not nil, the payload should get evaluated. That would ruin _everything_. The very purpose of the select statement is to _proceed_ the communication _as soon as possible_. If the select will first detect a ready-to-send channel and only after that evaluate the send value, evaluation of it may block! The whole concept then collapses immediately. > This semantic works in reverse. I disagree. -- -j -- 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.
