FWIW, either way the error message is not related to order of evaluation or
anything. It always happens with nil-channels:
https://play.golang.org/p/aBga7KFN30x
On Wed, Aug 8, 2018 at 5:46 PM Sam Whited wrote:
>
>
> On Wed, Aug 8, 2018, at 04:40, Jan Mercl wrote:
> > On Wed, Aug 8, 2018 at 11:15
On Wed, Aug 8, 2018, at 04:40, Jan Mercl wrote:
> On Wed, Aug 8, 2018 at 11:15 AM Kaveh Shahbazian
> wrote:
>
> > But the error message (no cases) is confusing and unclear because
> obviously there is a case there.
>
> I don't think it's confusing. The run-time message obviously does not talk
On Wed, Aug 8, 2018 at 11:15 AM Kaveh Shahbazian
wrote:
> But the error message (no cases) is confusing and unclear because
obviously there is a case there.
I don't think it's confusing. The run-time message obviously does not talk
about the compile-time case presence but about no case the selec
I did not say anything is incorrect. But the error message (no cases) is
confusing and unclear because obviously there is a case there. Something
like all channels of cases are nil is more clear or some other more
proper/clear message.
--
You received this message because you are subscribed to
i think the compiler has identified both problems correctly; c is nil (no
cases) and nothing is receiving from c (deadlock).
package main
func main() {
// var c chan struct{}
c := make(chan struct{})
go func(x chan struct{}) { <-x }(c)
select {
case c <- f():
}
}
func f() struct{} {
println("f c
According to this thread, for this program:
package main
func main() {
var c chan struct{}
select {
case c <- f():
}
}
func f() struct{} {
println("f called")
return struct{}{}
}
The error message in the output:
f called
fatal error: all goroutines are asleep - deadlock
On 24 January 2018 at 20:58, Axel Wagner wrote:
> On Wed, Jan 24, 2018 at 9:12 PM, roger peppe 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 s
You are right Alex.
And seems I am wrong and it does not really matter that much and is not a
fruitful topic.
--
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 go
On Wed, Jan 24, 2018 at 9:12 PM, roger peppe 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 (
> "l
On Wed, Jan 24, 2018 at 8:59 PM, dc0d wrote:
> It is as described in the spec. Regarding the specs it's correct. But
> that's not the reason.
>
You didn't ask for a reason this time, you ask for what is happening.
> The original question is about the "why".
>
> Why is that so? This behavior wa
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,
* dc0d [180124 14:44]:
>
> >
> > If the channel is nil, there's nothing to lock. But also, there's no
> > sending happening.
> >
>
> So first the payload is computed and then the nil check happens?
To add to what Axel said, it would be inconsistent to only evaluate the
LHS if the RHS was non-n
It is as described in the spec. Regarding the specs it's correct. But
that's not the reason.
The original question is about the "why".
Why is that so? This behavior was unexpected.
On Wednesday, January 24, 2018 at 11:20:01 PM UTC+3:30, Axel Wagner wrote:
>
> Both the channel and the value exp
>
> Both the channel and the value expression are evaluated before
> communication begins. Communication blocks until the send can proceed. A
> send on an unbuffered channel can proceed if a receiver is ready. A send on
> a buffered channel can proceed if there is room in the buffer. A send on a
>
>
> If the channel is nil, there's nothing to lock. But also, there's no
> sending happening.
>
So first the payload is computed and then the nil check happens?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
If the channel is nil, there's nothing to lock. But also, there's no
sending happening.
But the conceptual locking Ian mentions is there no matter whether you a)
first compute the value and then wait to be able to send, or b) first wait
to be able to send and then compute the value. In both cases,
Is this applied when the channel is nil? Does select statement first lock
the channel then check if it's nil?
On Wednesday, January 24, 2018 at 6:07:50 PM UTC+3:30, Ian Lance Taylor
wrote:
>
> On Tue, Jan 23, 2018 at 10:13 PM, dc0d > wrote:
> >
> > The third option was the expected one. Locki
On Tue, Jan 23, 2018 at 10:13 PM, dc0d wrote:
>
> The third option was the expected one. Locking aside (as the thought line
> behind the original question), the time spent on preparing/calculating a
> result value to be sent to a channel, is not directly relevant to the case
> for nil channels - w
The third option was the expected one. Locking aside (as the thought line
behind the original question), the time spent on preparing/calculating a
result value to be sent to a channel, is not directly relevant to the case
for nil channels - which were expected to get ignored. I do not understand
Marvin: That's pretty much the thinking behind the design. Thanks for the
clear explanation.
-rob
On Wed, Jan 24, 2018 at 5:31 AM, Marvin Renich wrote:
> * dc0d [180123 08:45]:
> > Can anybody help me understand the reason? (It's in the spec. That's not
> > the reason)
> >
> > On Sunday, Dece
* dc0d [180123 08:45]:
> Can anybody help me understand the reason? (It's in the spec. That's not
> the reason)
>
> On Sunday, December 31, 2017 at 10:14:31 AM UTC+3:30, dc0d wrote:
> >
> > Assume there is this select statement:
> >
> > for {
> > select {
> > // ...
> > // ...
> >
>
I don't think you can confidently make the claim 3. Nothing in the spec (or
basic logic) says, that a send on a nil-channel gets ignored, does it? The
case-block never gets executed, yes, but that's a consequence of the
effects a) send on a nil-channel blocks for ever and b) select waits for a
comm
1 - The case clause clearly represents a send action.
2 - So there must be a channel to send to, and f1() must return a channel.
3 - If that channel (returned by f1()) is nil, then the clause must get
ignored.
4 - If the returned channel (returned by f1()) is not nil, then f2() will
be executed.
On Tue, Jan 23, 2018 at 4:45 PM dc0d wrote:
> In the sample you have provided, a send syntax is used. And considering
that, (IMHO) f1() must be evaluated first.
Consider f1() is a dispatcher. If it is to be evaluated first then it may
create and return a new channel that will not be used. Or con
In the sample you have provided, a send syntax is used. And considering
that, (IMHO) f1() must be evaluated first.
On Tuesday, January 23, 2018 at 6:13:08 PM UTC+3:30, Ian Lance Taylor wrote:
>
> On Tue, Jan 23, 2018 at 5:44 AM, dc0d >
> wrote:
> >
> > Can anybody help me understand the reason
On Tue, Jan 23, 2018 at 5:44 AM, dc0d wrote:
>
> Can anybody help me understand the reason? (It's in the spec. That's not the
> reason)
It gives a precise order of evaluation of the select statement. Consider
case f1() <- f2():
It's useful to specify the order in which f1 and f2 are evaluate
Can anybody help me understand the reason? (It's in the spec. That's not
the reason)
On Sunday, December 31, 2017 at 10:14:31 AM UTC+3:30, dc0d wrote:
>
> Assume there is this select statement:
>
> for {
> select {
> // ...
> // ...
>
> case rcvd <- first():
> }
> }
>
>
> The
On Sun, Dec 31, 2017 at 1:15 PM dc0d wrote:
> Also the function first() may block on it's own.
That's the very purpose of the select statement!
1. Determine which cases can proceed and which cannot.
2. Randomly select one case which can proceed and perform the
communication, if there's any such
You really should see my code (again at playground:
https://play.golang.org/p/znlLnuT7_lQ). You will see your common sense
behavior is undesired.
The select statement literally does nothing to check if a channel is nil or
not and it is a coder's responsibilty to manage if first() is blockable or
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() may block on it's own. So, the select statement
might get blocked on a nil channel! That's bad!
The only reaso
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
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 different things.
> This behavior for case clause of select statemen
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
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
evaluate
On Sun, Dec 31, 2017 at 11:55 AM dc0d wrote:
> Please read the first message in this thread. The first() function was
expected to be ignored as in common sense, yet it gets evaluated.
>
> I am not wrong (or right), only making a point (maybe the point seems
pointless) and I have read the specs. I
Please read the first message in this thread. The first() function was
*expected* to be ignored as in common sense, yet it gets evaluated.
I am not wrong (or right), only making a point (maybe the point seems
pointless) and I have read the specs. I am saying that this behavior was
*unexpected*
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
Indeed. But case clauses of a select statement evaluate all expressions
even if the channel is nil, in which case it is ignored and it was expected
for other expressions to not get evaluated (which is not the case).
--
You received this message because you are subscribed to the Google Groups
"
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
Thanks!
Still it's the opposite of how a case works inside a switch statement.
I understand these are different contexts but this difference is a bit of
inconsistency and an unnecessary cognitive load (IMHO).
func main() {
switch {
case false && first() == 1:
case true:
log.Println("first
Hi,
I think your answer can be found in this
section: https://golang.org/ref/spec#SendStmt
"Both the channel and the *value expression are evaluated* before
communication begins"
cheers,
silviu
On Sunday, 31 December 2017 01:44:31 UTC-5, dc0d wrote:
>
> Assume there is this select statement:
41 matches
Mail list logo
