blob: 367bc7bc6fae6105eff07b90bd03803a10278f12 [file] [log] [blame]
Robert Griesemerd1582ac2020-01-23 22:02:51 -08001Proposals for Go 1.15
228 Jan 2020
3Tags: go1.15, proposals, community, language, vet
4
5Robert Griesemer, for the Go team
6gri@golang.org
7
8* Status
9
10We are close to the Go 1.14 release, planned for February assuming all goes
11well, with an RC1 candidate almost ready. Per the process outlined in the
Dmitri Shuralyove1c854a2020-01-31 19:13:19 +000012[[https://blog.golang.org/go2-here-we-come][Go 2, here we come!]] blog post,
Robert Griesemerd1582ac2020-01-23 22:02:51 -080013it is again the time in our development and release cycle to consider if and
14what language or library changes we might want to include for our next release,
15Go 1.15, scheduled for August of this year.
16
17The primary goals for Go remain package and version management, better error
18handling support, and generics. Module support is in good shape and getting
19better with each day, and we are also making progress on the generics front
20(more on that later this year). Our attempt seven months ago at providing a
21better error handling mechanism, the
22[[https://golang.org/issue/32437][`try` proposal]], met good support
23but also strong opposition and we decided to abandon it. In its aftermath there
24were many follow-up proposals, but none of them seemed convincing enough,
25clearly superior to the `try` proposal, or less likely to cause similar
26controversy. Thus, we have not further pursued changes to error handling
27for now. Perhaps some future insight will help us to improve upon the status
28quo.
29
30* Proposals
31
32Given that modules and generics are actively being worked on, and with error
33handling changes out of the way for the time being, what other changes should
34we pursue, if any? There are some perennial favorites such as requests for
35enums and immutable types, but none of those ideas are sufficiently developed
36yet, nor are they urgent enough to warrant a lot of attention by the Go team,
37especially when also considering the cost of making a language change.
38
39After reviewing all potentially viable proposals, and more importantly, because
40we dont want to incrementally add new features without a long-term plan, we
41concluded that it is better to hold off with major changes this time. Instead
42we concentrate on a couple of new `vet` checks and a minor adjustment to the
43language. We have selected the following three proposals:
44
45[[https://golang.org/issue/32479][#32479]].
46Diagnose `string(int)` conversion in `go`vet`.
47
48We were planning to get this done for the upcoming Go 1.14 release but we didn’t
49get around to it, so here it is again. The `string(int)` conversion was introduced
50early in Go for convenience, but it is confusing to newcomers (`string(10)` is
51`"\n"` not `"10"`) and not justified anymore now that the conversion is available
52in the `unicode/utf8` package.
53Since [[https://golang.org/issue/3939][removing this conversion]] is
54not a backwards-compatible change, we propose to start with a `vet` error instead.
55
56[[https://golang.org/issue/4483][#4483]].
57Diagnose impossible interface-interface type assertions in `go`vet`.
58
59Currently, Go permits any type assertion `x.(T)` (and corresponding type switch case)
60where the type of `x` and `T` are interfaces. Yet, if both `x` and `T` have a method
61with the same name but different signatures it is impossible for any value assigned
62to `x` to also implement `T`; such type assertions will always fail at runtime
63(panic or evaluate to `false`). Since we know this at compile time, the compiler
64might as well report an error. Reporting a compiler error in this case is not a
65backwards-compatible change, thus we also propose to start with a `vet` error
66instead.
67
68[[https://golang.org/issue/28591][#28591]].
69Constant-evaluate index and slice expressions with constant strings and indices.
70
71Currently, indexing or slicing a constant string with a constant index, or indices,
72produces a non-constant `byte` or `string` value, respectively. But if all operands
73are constant, the compiler can constant-evaluate such expressions and produce a
74constant (possibly untyped) result. This is a fully backward-compatible change
75and we propose to make the necessary adjustments to the spec and compilers.
76
Robert Griesemeraf231b02020-01-31 12:07:13 -080077(Correction: We found out after posting that this change is not backward-compatible;
78see [[https://golang.org/issue/28591#issuecomment-579993684][comment]] for details.)
79
Robert Griesemerd1582ac2020-01-23 22:02:51 -080080* Timeline
81
82We believe that none of these three proposals are controversial but theres
83always a chance that we missed something important. For that reason we plan
84to have the proposals implemented at the beginning of the Go 1.15 release cycle
85(at or shortly after the Go 1.14 release) so that there is plenty of time to
86gather experience and provide feedback. Per the
Dmitri Shuralyove1c854a2020-01-31 19:13:19 +000087[[https://blog.golang.org/go2-here-we-come][proposal evaluation process]],
Robert Griesemerd1582ac2020-01-23 22:02:51 -080088the final decision will be made at the end of the development cycle, at the
89beginning of May, 2020.
90
91* And one more thing...
92
93We receive many more language change proposals
94([[https://github.com/golang/go/labels/LanguageChange][issues labeled LanguageChange]])
95than we can review thoroughly. For instance, just for error handling alone,
96there are 57 issues, of which five are currently still open. Since the cost
97of making a language change, no matter how small, is high and the benefits
98are often unclear, we must err on the side of caution. Consequently, most
99language change proposals get rejected sooner or later, sometimes with minimal
100feedback. This is unsatisfactory for all parties involved. If you have spent a
101lot of time and effort outlining your idea in detail, it would be nice to not
102have it immediately rejected. On the flip side, because the general
103[[https://github.com/golang/proposal/blob/master/README.md][proposal process]]
104is deliberately simple, it is very easy to create language change proposals
105that are only marginally explored, causing the review committee significant
106amounts of work. To improve this experience for everybody we are adding a new
107[[https://github.com/golang/proposal/blob/master/go2-language-changes.md][questionnaire]]
108for language changes: filling out that template will help reviewers evaluate
109proposals more efficiently because they dont need to try to answer those
110questions themselves. And hopefully it will also provide better guidance for
111proposers by setting expectations right from the start. This is an experiment
112that we will refine over time as needed.
113
114Thank you for helping us improve the Go experience!