My concern was about a shared ok.
On Mon, Dec 25, 2017 at 1:22 PM, 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
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,
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
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
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 :=
Oh foo, if we only need a common behavior, we can call a function instead
of inlined code.
--
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
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
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:
//
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,
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,
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: //
11 matches
Mail list logo