Go: Proposal: Go 2: Smooth syntax for non-blocking channel

[nsagnett]

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.

[mpx]

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:

ok := chans.SendNonBlocking(fooCh, bar)

I think this would be preferable rather than adding various forms of limited custom syntax.

[ianlancetaylor]

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 <- for new Go users, and the distinction could be confusing.

(Historical note: in the early days of the language a non-blocking receive was written as v, ok := <-c and a non-blocking send was written as ok := c <- v. When we understood the use of closing channels and range and the implications for racy code, we changed v, ok := <-c to report whether the channel was closed, and dropped the non-blocking send. After all, even then, non-blocking operations could be done using select. See the discussion at https://groups.google.com/forum/#!topic/golang-dev/VK_L5x1EgBI).

[ianlancetaylor]

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.

[nsagnett]

Yes sorry, it was not clear but the suggested syntax will be :
Blocking Send : c <- v
Blocking Read : c := <- v
NonBlocking Send : c <~ v
NonBlocking Read : c := <~ v

[ianlancetaylor]

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.

[nsagnett]

Yes but I could see this syntax with Fire And Forget philosophy

[ianlancetaylor]

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 <- and <~, for a feature that few programs need.

[nsagnett]

Thanks for clarification