Re: [go-nuts] Re: select multiple expressions per case

2017-12-26 Thread Michael Jones
My concern was about a shared ok. On Mon, Dec 25, 2017 at 1:22 PM, wrote: > Well my almost-use-case was just for signaling without assignment. The > assignment cases are something that would need to be addressed by such a > feature. I like your pattern as a Go 1

Re: [go-nuts] Re: select multiple expressions per case

2017-12-25 Thread matthewjuran
Well my almost-use-case was just for signaling without assignment. The assignment cases are something that would need to be addressed by such a feature. I like your pattern as a Go 1 solution, but what are the unaddressed concerns? Thanks for the feedback, happy holidays. Matt On Sunday,

Re: [go-nuts] Re: select multiple expressions per case

2017-12-24 Thread Michael Jones
Many important concerns are unaddressed here. Inside the clause of a "v1 := <-c1" the identifier v1 has meaning -- it is the value by which one refers to the successful receipt. Inside the clause of a "v1, ok1 := <-c1" v1 is either the value received when ok1 is true or the zero value of the

Re: [go-nuts] Re: select multiple expressions per case

2017-12-22 Thread matthewjuran
David, There's a good argument for not spending time adding this to the spec and compilers: there are bigger issues for the existing language developers. Jason, I've suggested the non-receiving assignment is set to the zero value, ok only applies to the receiving assignment and can be used

Re: [go-nuts] Re: select multiple expressions per case

2017-12-21 Thread Jason Phillips
Matt, Would that mean that other receive expression(s) yield the zero value? select { case x := <-c1, y := <-c2: // If a value is received from c1, is y the zero value? } Would the multi-valued assignment form of the receive operator gain an additional meaning? select { case x, ok :=

Re: [go-nuts] Re: select multiple expressions per case

2017-12-21 Thread David Collier-Brown
Oh foo, if we only need a common behavior, we can call a function instead of inlined code. -- 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

Re: [go-nuts] Re: select multiple expressions per case

2017-12-21 Thread Jesper Louis Andersen
To generalize, you have a number of events, either send or receive, on channels. One could also imagine that timers are events of a special kind. Likewise, atomic updates, data swaps and so on are events in a generalized select statement. These can be combined, either through "and" style

Re: [go-nuts] Re: select multiple expressions per case

2017-12-21 Thread Jason Phillips
With a multiple expression switch statement, the associated case is executed if any expression is equal to the switch expression. For a multiple expression select, would all channel expressions have to proceed for the associated case to execute? e.g. select { case x := <-c1, y := <-c2: //

Re: [go-nuts] Re: select multiple expressions per case

2017-12-21 Thread matthewjuran
First the switch behavior surprised me when looking at how to stack cases, but then later I was surprised that select doesn't have the same thing. Consistency is the only reason to write it down, my concrete example doesn't need this as shown by Damien in the proposal. Matt On Wednesday,

Re: [go-nuts] Re: select multiple expressions per case

2017-12-20 Thread Rob Pike
There is no particular reason, it was just to keep things simple, if it was even talked about. I don't think it was. If you want to propose a change, now is a good time to do that. Not sure the idea is above the bar, though. -rob On Thu, Dec 21, 2017 at 9:39 AM,

[go-nuts] Re: select multiple expressions per case

2017-12-20 Thread matthewjuran
Tracker proposal for this: https://github.com/golang/go/issues/23196 Matt On Monday, December 18, 2017 at 10:11:02 AM UTC-6, matthe...@gmail.com wrote: > > I guess with select you can't do the comma for multiple cases having one > behavior like with switch: > > select{ > case <-c1, <-c2: //