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 type when ok1 is false.
Having multiple vNs and one Ok feels improper to me.
How about this as a way to do the "grouped response metaphor" you seek:
var v1, v2, ... vN appropriateValueTypes for channels c1..cN
var ok1, ok2, ... okN bool
// do the select with all case bodies empty
select {
case v1,ok1 = <- c1:
case v2,ok2 = <- c2:
:
case vN,okN = <- cN:
}
// decode the select
switch {
case ok1, ok2:
// common stuff coded once
case okN:
// solo stuff
}
On Fri, Dec 22, 2017 at 7:36 AM, <matthewju...@gmail.com> wrote:
> 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 twice since both
> are bool, and yes there are a lot of commas. Perhaps there could be special
> syntax for the multiple ok:
>
> select{
> case x := <-c1, y := <-c2, (ok):
> // ok is for whichever is assigned or closed
> }
>
> Maybe living with the commas isn't too bad:
>
> select{
> case x, ok := <-c1, y, ok := <-c2, z, ok := <-c3:
> // ok is for whichever is assigned or closed
> }
>
> Or how about ;? Two examples:
>
> select{
> case x, ok := <-c1; y, ok := <-c2:
> if ok == false {
> return
> }
> if x != false {
> fmt.Println("true on c1")
> break
> }
> fmt.Printf("non-zero %v on c2\n", y)
> case x, ok := <-c3; y, ok := <-c4:
> if ok == false {
> return
> }
> if x != 0 {
> fmt.Println(x)
> } else {
> fmt.Println(y)
> }
> continue
> case c5<-v1; c6<-v2; c7<-v3:
> break OUTER
> }
>
> select{
> case x, ok := <-c1
> y, ok := <-c2:
> if ok == false {
> return
> }
> if x != false {
> fmt.Println("true on c1")
> break
> }
> fmt.Printf("%v on c2\n", y)
> case x, ok := <-c3
> y, ok := <-c4
> z := <-c8:
> if ok == false {
> return
> }
> if x != 0 {
> fmt.Println(x)
> } else if y != nil {
> fmt.Println(y)
> } else {
> fmt.Println(z)
> }
> continue
> case c5<-v1
> c6<-v2
> c7<-v3:
> break OUTER
> }
>
> ok would be set to true if the receiving assignment does not assign it but
> other parallel assignments have it.
>
> Matt
>
>
> On Friday, December 22, 2017 at 12:44:03 AM UTC-6, Jason Phillips wrote:
>>
>> 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 := <-c1, y := <-c2:
>> // If a value is received from c2, does "ok" designate unsuccessful
>> receive or channel close?
>> }
>>
>> Additionally, the commas become awfully confusing with multiple
>> multi-valued assignments:
>>
>> select {
>> case x, ok1 := <-c1, y, ok2 := <-c2:
>> // Do something
>> }
>>
>>
>> Jason
>>
>> On Thursday, December 21, 2017 at 2:38:02 PM UTC-5, matthe...@gmail.com
>> wrote:
>>>
>>> I would assume only one would send/receive out of the comma list for a
>>> case to be executed.
>>>
>>> Matt
>>>
>>> On Thursday, December 21, 2017 at 12:32:22 PM UTC-6, Jason Phillips
>>> wrote:
>>>>
>>>> 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:
>>>> // is it guaranteed that both c1 and c2 have produced a value, or
>>>> just one or the other?
>>>> }
>>>>
>>>> What about send operations?
>>>>
>>>> select {
>>>> case c1 <- 10, c2 <- 20:
>>>> // is this only executed if both sends happened?
>>>> }
>>>>
>>>>
>>>> Jason
>>>>
>>>> On Thursday, December 21, 2017 at 9:04:35 AM UTC-5, matthe...@gmail.com
>>>> wrote:
>>>>>
>>>>> 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, December 20, 2017 at 6:51:36 PM UTC-6, Rob 'Commander'
>>>>> Pike wrote:
>>>>>>
>>>>>> 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, <matthe...@gmail.com> wrote:
>>>>>>
>>>>>>> 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: // gofmt: expected 1 expression
>>>>>>>> fmt.Println("c1 or c2")
>>>>>>>> case <-c3:
>>>>>>>> }
>>>>>>>>
>>>>>>>> switch s{
>>>>>>>> case v1, v2:
>>>>>>>> fmt.Println("v1 or v2")
>>>>>>>> case v3:
>>>>>>>> }
>>>>>>>>
>>>>>>>> I assume this is because select cases have an optional var
>>>>>>>> assignment. This would have been nice for detecting an explicit client
>>>>>>>> cancel action versus a w.(http.CloseNotifier).CloseNotify() where
>>>>>>>> the resulting server action is the same.
>>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>> --
>>>>>>> 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...@googlegroups.com.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>> --
> 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.
>
--
Michael T. Jones
michael.jo...@gmail.com
--
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.
