condition

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

To come to these changes in language, we started with several viable proposals, selected from a much larger list of Go 2 proposals , in accordance with the new proposal evaluation process described in the post “ Go 2, here we come !”. We wanted the initial selection of proposals by us to play a relatively small role and, for the most part, not cause controversy, so that with a high probability they would go through the whole process. The proposed changes had to be backward compatible in order to break as little as possible, since the modules(which in the future will allow you to select the language version for a particular module) are not yet the default build mode. Briefly, the current initial phase of the changes was more aimed at getting off the ground again and gaining experience, rather than solving big problems.

Our initial list of sentences - Unicode in the general form in identifiers , binary integer literals , delimiters for numeric literals , bit shifts by a signed integer - has been shortened and expanded. The proposal for Unicode in general terms in identifiers did not survive the reduction, because we did not manage to draw up a design document in time. The proposal for binary integer literals has been greatly expanded and has led to a comprehensive review and modernization of the syntax of Go numeric literals. We also added a draft Go 2 error checking proposal, which was partially accepted.

Given these initial changes to 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 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.

With the improvement of the Go module system, the problem of managing packages and versions is being addressed. Remain improved error handling and generics. We worked on both issues and presented draft design documents at 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). With regard to generics, we are working on it, on the subject on GopherCon in San Diego this year will take place performance of Ian Lance Taylor "Generics in Go", but we have not yet reached the stage where could provide a concrete proposal.

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

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

This is our suggestion 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 number 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. The first comment has a couple of links to a summary of the reviews. Please follow the feedback guidelines (see the “Next Steps” section) before replying.

# 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 view string(int)to go vet.

A view transformation string(int)has long been added to Go for convenience, however it is very confusing for beginners ( string(10)- this is "\n", not "10"), and is no longer justified, because now the conversion is available in the package unicode/utf8. Since deleting this transformation is not a backward compatible change, we propose instead to throw an error on execution go vet.

# 32466 . Accept cryptography design principles ( design document ).

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

Next steps

We are actively collecting feedback on all of these suggestions. We are especially interested in evidence showing why the proposal may not work well in practice, or in problematic aspects that we might have missed when developing. Convincing examples in support of suggestions are also very helpful. On the other hand, comments containing only personal opinions are less effective: we can take them into account, but we cannot constructively work with them. Before answering, please take a moment to read the 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 development cycle Go 1.14 (early August 2019), so that this can already be evaluated in practice. In accordance with the process of evaluating proposals, the final decision will be made at the end of the development cycle (early November 2019).

Thanks for helping improve the Go language!

Robert Griesemer, for the Go team