Skip to content
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: multiple value/tuple channels #41148

lolbinarycat opened this issue Aug 31, 2020 · 7 comments

proposal: Go 2: multiple value/tuple channels #41148

lolbinarycat opened this issue Aug 31, 2020 · 7 comments


Copy link

@lolbinarycat lolbinarycat commented Aug 31, 2020

There have been several requests over time for tuples to be added to go. However, that presents issues with return values. I propose a change with a much smaller scope: multi-value channels:

var multiChan := make(chan (int,string),3)

multiChan <- 6, "foo"
multiChan <- 7, "bar"

n, str  := <- multiChan
n2, str2, ok := multiChan // check if channel is closed

The reason for this is as follows:
Normally, you don't really need tuples because you can pass around multiple variable and just know that they are associated.
However, in an environment with multiple goroutines, you can't be sure exactly in what order things would happen, and the only way to associate related variables is with a struct type.

Here is the code that inspired me to write this (somewhat incomplete, as I stopped writing it

func getRootWinNameAtom() xproto.Atom {
	props, err := ListProperties(X,X.RootWin()).Reply()
	if err != nil {log.Fatal(err)}

	// this is why go needs tuples
	type CookieWithAtom = struct {
		C xproto.GetAtomNameCookie,
		A xproto.Atom,
	cookies := make(chan CookieWithAtom,props.AtomsLen)
	for _, atom := range props.Atoms {
		go func (atom xproto.Atom) {
			cookies <- CookiesWithAtom{GetAtomName(X,atom),atom}
		} (atom)

	type ReplyWithAtom = struct {
		R xproto.GetAtomNameReply,
		A xproto.Atom

	replies := make(chan ReplyWithAtom,props.Atoms)
	for i:=0;i<len(props.Atoms);i++ {
		go func {
			c := <-cookies
			replies <- ReplyWithAtom{c.R.Reply(),}
			log.Println("got reply")

As you can see, half the code is just defining temporary types to use, where as it would be much less with my proposal.

This problem would also be addressed somewhat by #1285, as it would allow easily using anonymous types in the type signature of the channel.

@gopherbot gopherbot added this to the Proposal milestone Aug 31, 2020
@gopherbot gopherbot added the Proposal label Aug 31, 2020
@ianlancetaylor ianlancetaylor changed the title Proposal: Multiple value/tuple channels proposal: Go 2: multiple value/tuple channels Aug 31, 2020
Copy link

@ianlancetaylor ianlancetaylor commented Aug 31, 2020

For language change proposals, please fill out the template at .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.


Copy link

@andig andig commented Sep 5, 2020

Why wouldn‘t one use a channel of struct instead?

Copy link

@lolbinarycat lolbinarycat commented Sep 7, 2020

Why wouldn't one use a channel of struct instead?

like I showed in my examples, that requires defining a new type (or typing out an anonymous struct type every time), which can be cumbersome.

Copy link

@lolbinarycat lolbinarycat commented Sep 7, 2020

Would you consider yourself a novice, intermediate, or experienced Go programmer?
intermediate, I guess. I haven't been using go for very long necessarily, but I have written a good deal of go code.

What other languages do you have experience with?
I have a bit of experience with:
haskell, rust, js, c and emacs-lisp (I might be forgetting something).

Would this change make Go easier or harder to learn, and why?
It would make it a little bit harder, but it wouldn't be a huge difference.

Has this idea, or one like it, been proposed before?
Some proposals have been made for tuples.

If so, how does this proposal differ?
It only applies to channels

Who does this proposal help, and why?
People who want to send associated data through a channel.

What is the proposed change?
Please describe as precisely as possible the change to the language.
It would be possible to send associated pairs/triples/etc. through channels.

What would change in the language spec?

Please also describe the change informally, as in a class teaching Go.
channels can now send and revive multiple values, similar to functions.

Is this change backward compatible?

Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.
Show example code before and after the change.
What is the cost of this proposal? (Every language change has a cost).
The biggest cost would probably be how it interacts with the optional ok paramater, as now seeing a, b := <- ch could have multiple meanings.

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
anything that cares about channels in a meaningful way.

What is the compile time cost?
the amount of variables that it is valid to assign via a channel receive now depends on the type of the channel.

What is the run time cost?

Can you describe a possible implementation?
A translation tool that changes multi-value send and receives into their anonymous struct type equivalent

Do you have a prototype? (This is not required.)
How would the language spec change?
channel types:

ChannelType = ( "chan" | "chan" "<-" | "<-" "chan" ) (ElementType | TupleType ) .
TupleType = "(" [ElementType [","] ] ")"

Orthogonality: how does this change interact or overlap with existing features?
The biggest overlap is with struct values.

Is the goal of this change a performance improvement?
If so, what quantifiable improvement should we expect?
How would we measure it?
Does this affect error handling?
not in any obvious way.
If so, how does this differ from previous error handling proposals?
Is this about generics?
If so, how does this differ from the the current design draft and the previous generics proposals?

Copy link

@lolbinarycat lolbinarycat commented Sep 7, 2020

@gopherbot please remove label WaitingForInfo

Copy link

@ianlancetaylor ianlancetaylor commented Sep 15, 2020

As mentioned above, we can just use a struct type. This proposal is syntactic sugar for that. If we're going to add a new tuple type, it should be more consistent than just syntactic sugar for channels. See also #32941.

Therefore, this is a likely decline. Leaving open for four weeks for final comments.

Copy link

@ianlancetaylor ianlancetaylor commented Oct 13, 2020

No further comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.