The point is, you will not know whether the caller send a nil or not.
dc0d於 2018年1月1日星期一 UTC+8上午1時27分29秒寫道：
>
> I do not see how it should make me panic. If it's nil, it will be ignored
> and if it's not nil only then calling first() should cause a dead lock.
> That's common sense.
>
> But since "it is working according to the spec", it seems I should live
> with this and move on.
>
> On Sunday, December 31, 2017 at 8:15:35 PM UTC+3:30, leaf...@gmail.com
> wrote:
>>
>>
>>
>> dc0d於 2017年12月31日星期日 UTC+8下午11時40分44秒寫道：
>>>
>>> Or the (not only) other option is check for nil channels before entering
>>> the scope of select?
>>>
>>
>> Change a little bit of your code.
>>
>> package main
>>
>>
>> import (
>> "log"
>> "time"
>> )
>>
>>
>> func main() {
>> f(nil)
>> f(make(chan bool))
>> }
>>
>>
>> func first() bool {
>> select {}
>> }
>>
>>
>> func f(rcvd chan bool) {
>> // for demonstration purpose
>> select {
>> case rcvd <- first():
>>
>> case <-time.After(time.Second):
>> log.Println("timeout")
>> }
>> log.Println("done")
>> }
>>
>>
>> func init() {
>> log.SetFlags(0)
>> }
>> Now you are living in panic (pun intended) with worries whether it block
>> or not, as you can not guarantee what value is passed into the function.
>>
>> Does this seem good or common sense to you?
>>
>
--
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.
