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