On 24 January 2018 at 20:58, Axel Wagner <axel.wagner...@googlemail.com> wrote:
> On Wed, Jan 24, 2018 at 9:12 PM, roger peppe <rogpe...@gmail.com> wrote:
>>
>> Why? Consider this code. When c is first evaluated, it's ok to send
>> on, so it would
>> evaluate f, but f causes c to be not ready, so f has been evaluated even
>> though
>> c cannot be sent on.
>>
>> package main
>>
>> import (
>> "log"
>> "time"
>> )
>>
>> func main() {
>> c := make(chan int, 1)
>> f := func() int {
>> c <- 1
>> return 0
>> }
>> select {
>> case c <- f():
>> case <-time.After(time.Second):
>> log.Printf("could not send value")
>> }
>> }
>
>
> This is a pretty cool counter-example. You can even take it one step further
>
> c := make(chan int, 1)
> f := func() int {
> c = nil
> return 0
> }
> select {
> case c <- f():
> }
>
> whoops.
I'm not sure that's quite as good because the left side of the <- operator
must be evaluated before f() is evaluated, so by the time f is
invoked, the select already knows the channel (it must be able
to store the channel because the expression on the left may be a function call)
--
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.
