content/go1.15-proposals.article - blog - Git at Google

 Proposals for Go 1.15
 28 Jan 2020
 Tags: go1.15, proposals, community, language, vet

 Robert Griesemer, for the Go team
 gri@golang.org

 * Status

 We are close to the Go 1.14 release, planned for February assuming all goes
 well, with an RC1 candidate almost ready. Per the process outlined in the
 [[https://blog.golang.org/go2-here-we-come][Go 2, here we come!]] blog post,
 it is again the time in our development and release cycle to consider if and
 what language or library changes we might want to include for our next release,
 Go 1.15, scheduled for August of this year.

 The primary goals for Go remain package and version management, better error
 handling support, and generics. Module support is in good shape and getting
 better with each day, and we are also making progress on the generics front
 (more on that later this year). Our attempt seven months ago at providing a
 better error handling mechanism, the
 [[https://golang.org/issue/32437][`try` proposal]], met good support
 but also strong opposition and we decided to abandon it. In its aftermath there
 were many follow-up proposals, but none of them seemed convincing enough,
 clearly superior to the `try` proposal, or less likely to cause similar
 controversy. Thus, we have not further pursued changes to error handling
 for now. Perhaps some future insight will help us to improve upon the status
 quo.

 * Proposals

 Given that modules and generics are actively being worked on, and with error
 handling changes out of the way for the time being, what other changes should
 we pursue, if any? There are some perennial favorites such as requests for
 enums and immutable types, but none of those ideas are sufficiently developed
 yet, nor are they urgent enough to warrant a lot of attention by the Go team,
 especially when also considering the cost of making a language change.

 After reviewing all potentially viable proposals, and more importantly, because
 we don’t want to incrementally add new features without a long-term plan, we
 concluded that it is better to hold off with major changes this time. Instead
 we concentrate on a couple of new `vet` checks and a minor adjustment to the
 language. We have selected the following three proposals:

 [[https://golang.org/issue/32479][#32479]].
 Diagnose `string(int)` conversion in `go`vet`.

 We were planning to get this done for the upcoming Go 1.14 release but we didn’t
 get around to it, so here it is again. The `string(int)` conversion was introduced
 early in Go for convenience, but it is confusing to newcomers (`string(10)` is
 `"\n"` not `"10"`) and not justified anymore now that the conversion is available
 in the `unicode/utf8` package.
 Since [[https://golang.org/issue/3939][removing this conversion]] is
 not a backwards-compatible change, we propose to start with a `vet` error instead.

 [[https://golang.org/issue/4483][#4483]].
 Diagnose impossible interface-interface type assertions in `go`vet`.

 Currently, Go permits any type assertion `x.(T)` (and corresponding type switch case)
 where the type of `x` and `T` are interfaces. Yet, if both `x` and `T` have a method
 with the same name but different signatures it is impossible for any value assigned
 to `x` to also implement `T`; such type assertions will always fail at runtime
 (panic or evaluate to `false`). Since we know this at compile time, the compiler
 might as well report an error. Reporting a compiler error in this case is not a
 backwards-compatible change, thus we also propose to start with a `vet` error
 instead.

 [[https://golang.org/issue/28591][#28591]].
 Constant-evaluate index and slice expressions with constant strings and indices.

 Currently, indexing or slicing a constant string with a constant index, or indices,
 produces a non-constant `byte` or `string` value, respectively. But if all operands
 are constant, the compiler can constant-evaluate such expressions and produce a
 constant (possibly untyped) result. This is a fully backward-compatible change
 and we propose to make the necessary adjustments to the spec and compilers.

 * Timeline

 We believe that none of these three proposals are controversial but there’s
 always a chance that we missed something important. For that reason we plan
 to have the proposals implemented at the beginning of the Go 1.15 release cycle
 (at or shortly after the Go 1.14 release) so that there is plenty of time to
 gather experience and provide feedback. Per the
 [[https://blog.golang.org/go2-here-we-come][proposal evaluation process]],
 the final decision will be made at the end of the development cycle, at the
 beginning of May, 2020.

 * And one more thing...

 We receive many more language change proposals
 ([[https://github.com/golang/go/labels/LanguageChange][issues labeled LanguageChange]])
 than we can review thoroughly. For instance, just for error handling alone,
 there are 57 issues, of which five are currently still open. Since the cost
 of making a language change, no matter how small, is high and the benefits
 are often unclear, we must err on the side of caution. Consequently, most
 language change proposals get rejected sooner or later, sometimes with minimal
 feedback. This is unsatisfactory for all parties involved. If you have spent a
 lot of time and effort outlining your idea in detail, it would be nice to not
 have it immediately rejected. On the flip side, because the general
 [[https://github.com/golang/proposal/blob/master/README.md][proposal process]]
 is deliberately simple, it is very easy to create language change proposals
 that are only marginally explored, causing the review committee significant
 amounts of work. To improve this experience for everybody we are adding a new
 [[https://github.com/golang/proposal/blob/master/go2-language-changes.md][questionnaire]]
 for language changes: filling out that template will help reviewers evaluate
 proposals more efficiently because they don’t need to try to answer those
 questions themselves. And hopefully it will also provide better guidance for
 proposers by setting expectations right from the start. This is an experiment
 that we will refine over time as needed.

 Thank you for helping us improve the Go experience!
	Proposals for Go 1.15
	28 Jan 2020
	Tags: go1.15, proposals, community, language, vet

	Robert Griesemer, for the Go team
	gri@golang.org

	* Status

	We are close to the Go 1.14 release, planned for February assuming all goes
	well, with an RC1 candidate almost ready. Per the process outlined in the
	[[https://blog.golang.org/go2-here-we-come][Go 2, here we come!]] blog post,
	it is again the time in our development and release cycle to consider if and
	what language or library changes we might want to include for our next release,
	Go 1.15, scheduled for August of this year.

	The primary goals for Go remain package and version management, better error
	handling support, and generics. Module support is in good shape and getting
	better with each day, and we are also making progress on the generics front
	(more on that later this year). Our attempt seven months ago at providing a
	better error handling mechanism, the
	[[https://golang.org/issue/32437][`try` proposal]], met good support
	but also strong opposition and we decided to abandon it. In its aftermath there
	were many follow-up proposals, but none of them seemed convincing enough,
	clearly superior to the `try` proposal, or less likely to cause similar
	controversy. Thus, we have not further pursued changes to error handling
	for now. Perhaps some future insight will help us to improve upon the status
	quo.

	* Proposals

	Given that modules and generics are actively being worked on, and with error
	handling changes out of the way for the time being, what other changes should
	we pursue, if any? There are some perennial favorites such as requests for
	enums and immutable types, but none of those ideas are sufficiently developed
	yet, nor are they urgent enough to warrant a lot of attention by the Go team,
	especially when also considering the cost of making a language change.

	After reviewing all potentially viable proposals, and more importantly, because
	we don’t want to incrementally add new features without a long-term plan, we
	concluded that it is better to hold off with major changes this time. Instead
	we concentrate on a couple of new `vet` checks and a minor adjustment to the
	language. We have selected the following three proposals:

	[[https://golang.org/issue/32479][#32479]].
	Diagnose `string(int)` conversion in `go`vet`.

	We were planning to get this done for the upcoming Go 1.14 release but we didn’t
	get around to it, so here it is again. The `string(int)` conversion was introduced
	early in Go for convenience, but it is confusing to newcomers (`string(10)` is
	`"\n"` not `"10"`) and not justified anymore now that the conversion is available
	in the `unicode/utf8` package.
	Since [[https://golang.org/issue/3939][removing this conversion]] is
	not a backwards-compatible change, we propose to start with a `vet` error instead.

	[[https://golang.org/issue/4483][#4483]].
	Diagnose impossible interface-interface type assertions in `go`vet`.

	Currently, Go permits any type assertion `x.(T)` (and corresponding type switch case)
	where the type of `x` and `T` are interfaces. Yet, if both `x` and `T` have a method
	with the same name but different signatures it is impossible for any value assigned
	to `x` to also implement `T`; such type assertions will always fail at runtime
	(panic or evaluate to `false`). Since we know this at compile time, the compiler
	might as well report an error. Reporting a compiler error in this case is not a
	backwards-compatible change, thus we also propose to start with a `vet` error
	instead.

	[[https://golang.org/issue/28591][#28591]].
	Constant-evaluate index and slice expressions with constant strings and indices.

	Currently, indexing or slicing a constant string with a constant index, or indices,
	produces a non-constant `byte` or `string` value, respectively. But if all operands
	are constant, the compiler can constant-evaluate such expressions and produce a
	constant (possibly untyped) result. This is a fully backward-compatible change
	and we propose to make the necessary adjustments to the spec and compilers.

	* Timeline

	We believe that none of these three proposals are controversial but there’s
	always a chance that we missed something important. For that reason we plan
	to have the proposals implemented at the beginning of the Go 1.15 release cycle
	(at or shortly after the Go 1.14 release) so that there is plenty of time to
	gather experience and provide feedback. Per the
	[[https://blog.golang.org/go2-here-we-come][proposal evaluation process]],
	the final decision will be made at the end of the development cycle, at the
	beginning of May, 2020.

	* And one more thing...

	We receive many more language change proposals
	([[https://github.com/golang/go/labels/LanguageChange][issues labeled LanguageChange]])
	than we can review thoroughly. For instance, just for error handling alone,
	there are 57 issues, of which five are currently still open. Since the cost
	of making a language change, no matter how small, is high and the benefits
	are often unclear, we must err on the side of caution. Consequently, most
	language change proposals get rejected sooner or later, sometimes with minimal
	feedback. This is unsatisfactory for all parties involved. If you have spent a
	lot of time and effort outlining your idea in detail, it would be nice to not
	have it immediately rejected. On the flip side, because the general
	[[https://github.com/golang/proposal/blob/master/README.md][proposal process]]
	is deliberately simple, it is very easy to create language change proposals
	that are only marginally explored, causing the review committee significant
	amounts of work. To improve this experience for everybody we are adding a new
	[[https://github.com/golang/proposal/blob/master/go2-language-changes.md][questionnaire]]
	for language changes: filling out that template will help reviewers evaluate
	proposals more efficiently because they don’t need to try to answer those
	questions themselves. And hopefully it will also provide better guidance for
	proposers by setting expectations right from the start. This is an experiment
	that we will refine over time as needed.

	Thank you for helping us improve the Go experience!