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, December 24, 2017 at 12:41:04 PM UTC-6, Michael Jones wrote:
>
> 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, <matthe...@gmail.com <javascript:>>
> 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...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Michael T. Jones
> michae...@gmail.com <javascript:>
>
--
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.
