condition

We are working hard on Go 1.13, the release of which, I hope, will take place in early August of this year. This is the first release that will include changes specifically in the language (and not just minor revisions of the specification) after a lengthy moratorium on any such changes.

To arrive at these changes in language, we began with several viable proposals (proposals) selected from a much larger list of proposals for Go 2 , in accordance with the new process for evaluating proposals described in the post “ Go 2, here we come !”. We wanted the initial selection of proposals to play a relatively small role and, for the most part, did not cause controversy, so that they would most likely go through the whole process. The proposed changes had to be backward compatible in order to break down as little as possible, since the modules (which in the future will allow to choose the language version for a particular module) are not yet the default build mode. In short, the current initial stage of change was more aimed at getting the ball rolling again and gaining experience, rather than solving major problems.

Our initial list of sentences — Unicode in general form in identifiers , binary integer literals , separators for numeric literals , bit shifts to a signed integer — was both shortened and expanded. The general proposal for Unicode in identifiers did not survive the abbreviation, because we did not have time to draw up a design document. The proposal for binary integer literals has been greatly expanded and has led to a comprehensive revision and update of the syntax of numeric Go literals. We also added a draft version of Go 2 error checking, which was partially accepted.

With these initial changes in Go 1.13, it's time to think about the future of Go 1.14 and determine what we want to change next.

Suggestions for Go 1.14

The goals that we set for Go today are the same as in 2007: to make software development scalable . The three main obstacles to improving scalability for Go are the lack of a package and version management system, support for a better error handling system, and generics.

By improving the system of Go modules, the problem of package and version management is solved. Improved error handling and generics remain. We worked on both issues and submitted draft designs to last year’s GopherCon in Denver. Since then, we have gradually improved them. On error handling, we published a significantly revised and simplified proposal (see below). As for generics, we are working on this, on this topic at GopherCon in San Diego this year, Ian Lance Taylor’s presentation "Generics in Go" will take place , but we have not yet reached the stage where we could provide a concrete proposal.

We also want to continue to gradually improve the language itself. For Go 1.14, we chose the following sentences:

# 32437 . The built-in error checking function is “try” ( design document ).

This is our proposal for improving error handling. Although the proposed backward compatible language extension is small, we expect a significant impact on the error handling code. This proposal has already caused a huge amount of comments, and this is not so easy to follow. We recommend starting with the first comment for a brief description and then reading the detailed design document. In the first comment there are a couple of links to the summary of reviews. Please follow the feedback recommendations (see the “Next Steps” section) before answering.

# 6977 . Allow embedding of overlapping interfaces ( design document ).

This is an old backward compatible proposal to make embedding interfaces more tolerant.

# 32479 . Warn about converting the form string(int) to go vet .

Converting the form string(int) has long been added to Go for convenience, but it is very confusing for newbies ( string(10) is "\n" , not "10" ) and is no longer justified, since the conversion is now available in the unicode/utf8 . Since the removal of this transformation is not a backward compatible change, we suggest instead giving an error when doing a go vet .

# 32466 . Adopt cryptographic design principles ( design document ).

This is a request for feedback on a set of cryptographic library design principles that we would like to adopt. See also the relevant proposal for removing SSLv3 support from crypto/tls .

Next steps

We are actively collecting feedback on all of these suggestions. We are particularly interested in evidence that shows why a proposal might work poorly in practice, or in problematic aspects that we might have missed when developing. Convincing examples in support of proposals are also very helpful. On the other hand, comments containing only personal opinions are less effective: we can take them into account, but cannot work constructively with them. Before answering, please take time to read detailed design documents and previous reviews or their summary. Your topic may have already been raised and discussed in previous comments, especially during long discussions.

If these proposals do not meet obvious problems, then we plan to implement everything at the beginning of the Go 1.14 development cycle (beginning of August 2019) so that this can be evaluated in practice. In accordance with the proposal evaluation process, the final decision will be made at the end of the development cycle (early November 2019).

Thank you for helping to improve the Go language!

Robert Griesemer, for the Go team