proposal: Go 2: change chan syntax from <- to "in out"

[dmitryuck]

Would you consider yourself a novice, intermediate, or experienced Go programmer?

• novice What other languages do you have experience with?
• Js, Ts, C# Would this change make Go easier or harder to learn, and why?
• convenient in a particular case Has this idea, or one like it, been proposed before?
• even don't know Who does this proposal help, and why? -go programmers What is the proposed change?
• chan usage Please describe as precisely as possible the change to the language. // in/out channel var c chan string

// write data to the channel "Hello world" in c

// read data from channel var data := out c

// read-only channel var c out chan int

func do(c in chan string) {}

Or add "->" operator

// write data to the channel "Hello world" -> c

// read data from channel var data := <- c

What would change in the language spec? Please also describe the change informally, as in a class teaching Go.

• You can think bivalent Is this change backward compatible?
• no Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit. Show example code before and after the change.

// before var c chan string c <- "Hello world"

var data := <- c

// after var c chan string "Hello world" -> c

// or "Hello world" in c

var data := out c

What is the cost of this proposal? (Every language change has a cost).

• unknown How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
• none What is the compile time cost?
• none What is the run time cost?
• none Can you describe a possible implementation?
• no Do you have a prototype? (This is not required.)
• no How would the language spec change?
• no Orthogonality: how does this change interact or overlap with existing features?
• nil Is the goal of this change a performance improvement?
• nil If so, what quantifiable improvement should we expect?
• nil How would we measure it?
• nil Does this affect error handling?
• nil If so, how does this differ from previous error handling proposals?
• nil Is this about generics?
• no If so, how does this differ from the current design draft and the previous generics proposals?
• nil

[mvdan]

Please note that you should fill https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing a language change.

[mdlayher]

Please keep in mind the first point here: https://github.com/golang/proposal/blob/master/go2-language-changes.md#what-to-avoid

Your proposal simply changes syntax from X to Y because you prefer Y.

[dmitryuck]

Or add "->" operator

// write data to the channel "Hello world" -> c

// read data from channel var data := <- c

[ianlancetaylor]

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

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

Thanks!

[dmitryuck]

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

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

Thanks!

@gopherbot please remove label WaitingForInfo

[ianlancetaylor]

This seems to just be suggesting an alternate syntax for something that we can already do. It would add new keywords to the language, breaking existing code. The benefit is not worth the cost. Also the emoji voting is not in favor of this change.

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

[theohogberg]

I don't personally agree with this!

The arrows in go have a direct historical link to unix, linux which are two most used OS:es for software/hardware nerds. They represented shorthands for reading/writing between files/programs as < and > symbols there.

If this had to be included the keyword should be "into" rather than "in" as it makes more sense. "in" is a keyword that can be used in javascript as a bool comparator for looking into objects, example: "sausage" in bread where "bread" is a js object.

It just adds confusion IMO, and if you like that type of confusion and ambiguity you should stick too the React & tc39 world

[ianlancetaylor]

No change in consensus.