With Go 1.13 well on its way to a release in August, proposals to implement for the next version of the programming language have been chosen. Robert Griesemer, a member of the Go team and one of the language’s designers, has taken to the Go blog to inform the community about the four selected improvements.

Since error handling has been on the list of issues to tackle for a while now, the first proposal for an error check function has already been revised and simplified a lot since it was presented last year. It is called try and is meant to “eliminate the boilerplate if statements typically associated with error handling in Go”. 

The extension is planned to be used following the pattern func try(expr) (T1, T2, … Tn) with expr being a function call most of the time “producing n+1 result values of types T1, T2, … Tn, and error for the last value. If expr evaluates to a single value (n is 0), that value must be of type error and try doesn’t return a result. Calling try with an expression that does not produce a last value of type error leads to a compile-time error.”

This “syntactic sugar” as the design document calls it, is supposed to make error handling more lightweight and therefore get more programmers to write corresponding code. Not the worst idea if you consider that much of today’s container infrastructure is written in Go.

After some changes the extension to the language is backwards-compatible so shouldn’t break existing code. Other than that, opinions on proposals to allow the embedding of overlapping interfaces, find a way to get rid of confusing string(int) conversions, and the adoption of design principles for cryptographic libraries are sought. 

Devs are called to give feedback and especially fact-based evidence should they see a proposal not working in practice. Should no strong reasons against moving the proposals to the experimental stage arise, implementations should be ready for evaluation in August 2019. The final decision on the inclusion will then be made in November.

Opening the floor up to comments like this and picking up only a couple of changes at a time is a practice that got introduced to the Go community in late 2018. Back then Griesemer wrote “We are constrained by the fact that we now have millions of Go programmers and a large body of Go code, and we need to bring it all along, lest we risk a split ecosystem. That means we cannot make many changes, and the changes we are going to make need to be chosen carefully.”

The release of Go 1.13 will be the first to have followed the proposal evaluation process, which starts with the Go team selecting proposals, and is followed by a sort of loop of community feedback, implementation and evaluation.