On the road to Go 2: Officially starting the Go 2 proposal evaluation process

In 2015, Go introduced a proposal process for any language or library changes. Anything that didn’t follow Go’s backwards compatibility promise got labelled as “for Go 2” and the issue was put off until later. Now, there are around 120 open Go 2 proposals waiting for love on GitHub.

Thankfully, Ian Lance Taylor and Robert Griesemer have been going through these proposals, categorizing and collating the various ideas into actionable groups. As they’ve trawled through these proposals, two major themes have emerged: support for better handling and generics. These two proposals have gotten a lot of attention at GopherCon with draft designs and more.

However, the rest need work, especially given the size of the Go community. No one wants a split ecosystem. So, how are we going to shepherd millions of Go programmers to the promised land of Go 2?

Proposal evaluation process

So, how are we going to add any of these proposals? Since this is the first major release upgrade for Go, we’re all making it up as we go along. That’s where the proposal evaluation process comes in.

The process collects feedback on a couple of proposals so the community can make a final decision. This should run in parallel to a release cycle.

1. Proposal selection. The Go team makes the initial selection from all the proposals based on what they think seems worthy of consideration.
2. Proposal feedback. Time for the community to chime in and make suggestions or express concerns.
3. Implementation. Proposals are implemented based on community feedback. Anything with significant language or library changes is to have them ready to submit on day 1 of the upcoming release cycle.
4. Implementation feedback. During the development cycle, the Go team and community have a chance to experiment with the new features and collect further feedback.
5. Launch decision. The Go team will make the final decision at the end of the three month development cycle based on the experience and feedback gathered during the release cycle. This is a chance to evaluate if the change has made any progress for the issue or caused any downstream effects. Once shipped, the changes become part of the language and libraries. Excluded proposals may go back to the drawing board or may be declined for good.

There are a lot of opportunities for feedback in this process. Hopefully, this should prevent feature creep or language bloat!

SEE ALSO: Go 2 error handling will bring a new errors idiom to the language

Proposal selection criteria

A proposal must:

1. Address an important issue for many people,
2. Have minimal impact on everybody else, and
3. Come with a clear and well-understood solution.

Right now, there are three possible backwards-compatible language proposals on the docket for the Go 1.13 release.

1. #20706 – General Unicode identifiers based on Unicode TR31: This addresses an important issue for Go programmers using non-Western alphabets and should have little if any impact on anyone else. There are normalization questions which we need to answer and where community feedback will be important, but after that the implementation path is well understood. Note that identifier export rules will not be affected by this.
2. #19308, #28493 Binary integer literals and support for_ in number literals: These are relatively minor changes that seem hugely popular among many programmers. They may not quite reach the threshold of solving an “important issue” (hexadecimal numbers have worked well so far) but they bring Go up to par with most other languages in this respect and relieve a pain point for some programmers. They have minimal impact on others who don’t care about binary integer literals or number formatting, and the implementation is well understood.
3. #19113 Permit signed integers as shift counts: An estimated 38% of all non-constant shifts require an (artificial) uint conversion (see the issue for a more detailed break-down). This proposal will clean up a lot of code, get shift expressions better in sync with index expressions and the built-in functions cap and len. It will mostly have a positive impact on code. The implementation is well understood.

SEE ALSO: Go in transition: Making sure the move from Go 1 to Go 2 goes smoothly

The road ahead to Go 2

Now that we have our three proposals, it’s time to get to the second step of the evaluation process: feedback. Right now, there are two full months of feedback planned before the changes can be implemented in the next release cycle on February 1, 2019.

These changes will enjoy a 3-month trial period during the development cycle from February to May 2019. The community will be able to try them out and give their feedback. Shortly after the repo freeze on May 1, 2019, the Go team will make a final decision on keeping the new features for good or abandoning them.

FYI: Since there is a real chance that a feature may need to be removed just when we freeze the repo, the implementation will need to be such that the feature can be disabled without destabilizing the rest of the system. For language changes that may mean that all feature-related code is guarded by an internal flag.

Again, it’s important to remember that this is the first time Go is going through this process. The repo freeze is also going to be a point where everyone reflects on the proposal process as well. Expect changes if it’s more trouble than it’s worth.

Now is your chance to be heard.  Head on over to the Golang proposal page and get to work on those proposals!

The post On the road to Go 2: Officially starting the Go 2 proposal evaluation process appeared first on JAXenter.