My concern was about a shared ok.
On Mon, Dec 25, 2017 at 1:22 PM, <matthewju...@gmail.com> 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 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> 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/golan
>>>>>>>>> g/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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Michael T. Jones
>> michae...@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.
>
--
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.
