> How putting one channel inside the parameters has not any effect on the logic
> of that select statement.
True.
My point is, whether a channel is nil or not is often not known to the coder,
and this whether the first will be called or not is unknown. Pass the channel
as a parameter emphasize
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
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
dc0d於 2017年12月31日星期日 UTC+8下午8時21分29秒寫道：
>
> Consider this:
>
> func first() bool {
> select {}
> }
>
>
> And inside another function/goroutine:
>
> func f() {
> var rcvd chan bool
> select {
> case rcvd <- first():
> }
> }
>
> While rcvd is nil, this select statement (inside f) will block, f
kable or
even meant to be blocked.
dc0d於 2017年12月31日星期日 UTC+8下午8時15分04秒寫道：
>
> Thanks leafbebop! Thanks Jan!
>
> I'm not convinced that, this might be a performance problem. Both actions
> happens anyway, so the total time would be the same.
>
> Also the function first()
Jan Mercl於 2017年12月31日星期日 UTC+8下午8時05分07秒寫道：
>
> On Sun, Dec 31, 2017 at 12:48 PM dc0d >
> 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 d
I get your point now, but I would not say it is common sense.
When using a channel, what matters is what to send to the data, not what
the channel is. If `case` evaluation behaves different depending on whether
chan is nil, it is a big surprise and may raise many bugs.
It is a pattern in go tha
Thank you for the insight. I didn't know that.
But would it make more sense to throw an error in this case? Is there any
missing points for an un-used private global variable?
I feel like to file an issue on github but kind of unsure.
Vasko Zdravevski於 2017年12月31日星期日 UTC+8上午1時26分59秒寫道：
>
> I thin
I think you got it wrong.
`select` is never about evaluating, but about blocking. It picks a case
that is not blocked at the moment (or one of them, ramdomly) and a nil
channel never block. It has nothing to do with any evaluation.
dc0d於 2017年12月31日星期日 UTC+8下午6時27分41秒寫道：
>
> Indeed. But case cla
I think it is well described as "short-circuit evaluation". It is common in
almost every popular programing languages (as far as I can tell).
In short, it means in `true || A()` A is never called and in `false && B()`
B is never called.
It is the reason you can write something like ` if n
> Than
Hi all, suddenly I found the code
package main
import (
"fmt"
)
var x=3
func main() {
fmt.Println("Hello, playground")
}
It works fun, which surprised me. I mean, I get the idea that public global
variable can be exported so it will not trigger "the declared but not used"
error, but
11 matches
Mail list logo
