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.
