Go: 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.