New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: spec: select: multiple case expressions or fallthrough keyword #23196
Comments
If you have |
Both variables would have to be used in the case block:
Comma ok is another case too:
Maybe since ok is always a bool it can have the same name:
There's the problem of the zero-value being sent on the chan meaning the block can't figure out which var to use. |
Your example use case could be written without duplication as: select {
case <-rdy:
return // the client redirects to a GET /competitive15
case <-cancel:
case <-w.(http.CloseNotifier).CloseNotify():
}
competitive15Matcher.Cancel(name)
http.NotFound(w, r) // the client ignores the POST response
return |
That makes sense. I don't have a good example use case. |
@mvdan despite the Go 2 tag do you think this could be a Go 1 feature? It doesn't seem like a breaking change. |
There will be no more significant changes to the language before Go 2.0, so I would say very unlikely. |
Our use case is similar to @pciet's example. We have a We ended up moving that into a function. Felt bad to allocate resources on every function call. I'll try @neild's solution and report if we land into some other problem. A hypothetical case which wouldn't work this way:
|
|
When used with sends on a channel, there is no way to tell which send succeeded in a case. When used with receives that happen to receive the zero value, there is no way to tell which receive succeeded in a case (particularly important since receives from a closed channel get the zero value). The same functionality can also be easily obtained with our current select by factoring out the case bodies. |
Unlike switch, select can only have one expression per case which may force code duplication or a separated function. This proposal is to add the option of multiple select case expressions.
Instead of:
An example with assignment:
In more detail, the proposal is that multiple expressions for a select case is equivalent to individually cased expressions with a duplicated code block, plus the requirement of all assignments used in the single code block.
My use case is a web page where a browser close and a cancel button press cause the same cancel to occur in a concurrent request. In my case there are only two lines of code duplicated:
The cases are different (CloseNotify doesn't need the http.NotFound) but the idea remains. Originally posted to golang-nuts: https://groups.google.com/forum/#!topic/golang-nuts/ROxbuskAglc
The text was updated successfully, but these errors were encountered: