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: Go 2: Smooth syntax for non-blocking channel #34203
Comments
The Contracts draft design suggests that this functionality could be a library function without requiring specific syntax (if/when Contracts are added). A hypothetical example:
I think this would be preferable rather than adding various forms of limited custom syntax. |
Nonblocking reads from channels have their place, but they are not the normal case. It's not clear to me that this is something that comes up often enough to justify adding a new syntax for it. Especially since the new syntax would presumably be as cryptic as (Historical note: in the early days of the language a non-blocking receive was written as |
Let me also say that it's essentially impossible to evaluate this proposal without a specific syntax to consider. So you'll need to propose a syntax. |
Yes sorry, it was not clear but the suggested syntax will be : |
Thanks. I think that in practice there would need to be some way to know whether the non-blocking send or receive actually sent or received a value. |
Yes but I could see this syntax with Fire And Forget philosophy |
A "Fire and Forget philosophy" sounds to me like something that is so special purpose that there is no need to support it with special syntax. We don't need to complicate the language, particularly with a subtle and nearly invisible distinction between |
Thanks for clarification |
Usually syntax for channel is smooth but only for blocking interaction.
When multiple channels are used in same goroutine,
select { case: }
syntax is very pretty and useful.However, when an only one channel is using and we don't want blocking process, we have to write complete syntax with default case, even if it's not required:
select { case foo <- bar: default: }
So, why not integrate new syntax like
<~
for non blocking interaction with channels.The text was updated successfully, but these errors were encountered: