content: add go1.15-proposals.article
Change-Id: Iece46c6e47ad2ee2ea003d73615792114f0117af
Reviewed-on: https://go-review.googlesource.com/c/blog/+/216199
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
diff --git a/content/go1.15-proposals.article b/content/go1.15-proposals.article
new file mode 100644
index 0000000..01bfe48
--- /dev/null
+++ b/content/go1.15-proposals.article
@@ -0,0 +1,111 @@
+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!
