This has almost nothing to do with case statements or switches. Switch cases 
are expressions, expressions have a defined evaluation process. That process 
includes short circuiting boolean logic. Channel sends on the other hand have 
no such short circuiting, whether used in a select case or not. There is no 
more eagerness in a select case than anywhere else. Consider:

foo := true || fn()

someBoolChan <- true || fn()

select {
  case someBoolChan <- true || fn():
}

In none of those three cases is fn called. In neither of the channel sends is 
the evaluation of the expression on the right dependent on whether the channel 
is nil or not.

//jb

On 31 Dec 2017, at 12:47, dc0d 
<kaveh.shahbaz...@gmail.com<mailto:kaveh.shahbaz...@gmail.com>> wrote:

Indeed everything works according to the specs. That is what is being 
questioned (the specs).

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.

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.

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.

This semantic works in reverse.

--
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<mailto: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.

Reply via email to