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 semantics (all events
must fire at the same time) or via "or" style semantics (if at least one
event can fire, then the statement can fire). You can have arbitrary
expressions of events, as in (<-Ch1 AND <-Ch2) OR (Ch2<- x). In an "or" the
system is likely left-biased: we only allow disjunctive normal form and we
check the disjunctions one at a time until we find one that will not block.
The alternative is a random-biased "or", but you already have that in Go.
Another notation might be to add the notion of non-blocking events, which
will always commit but make a note that they did not fire.
Next up, you must define some kind of binding rule for when an event fires.
That is, what name do you give every receiving clause and in what order? It
might be necessary to come up with a pattern matching system for this.
But one has to balance the added complexity out against its usefulness.
What can be achieved by other means and built up of simpler constructions
is almost always desirable in comparison to a more involved notation. It is
often better to add a minimal core functionality to the language as a tool
and then use that tool in a library to improve matters. I.e., rather than
making something like the `context` package into a language construct, find
a shortcoming of it and add that to the core language so you can extend
`context` with the missing piece.
On Thu, Dec 21, 2017 at 8:37 PM <matthewju...@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.
>
--
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.
