Go 官方博客
Go 1.15 提案
状态
Go 1.14 版本即将发布，如果一切顺利，计划于 2 月发布，RC1 候选版本已基本准备就绪。根据 Go 2，我们来了！ 博客文章中概述的流程，现在又到了我们在开发和发布周期中考虑是否以及希望为下一个版本 Go 1.15（计划于今年 8 月发布）包含哪些语言或库更改的时候了。
Go 的主要目标仍然是包和版本管理、更好的错误处理支持以及泛型。模块支持状况良好，并且每天都在改进，我们也在泛型方面取得进展（今年晚些时候会有更多介绍）。七个月前，我们尝试提供更好的错误处理机制，即 try 提案，获得了良好的支持，但也遭到了强烈反对，因此我们决定放弃它。在那之后，有很多后续提案，但没有一个看起来足够令人信服，明显优于 try 提案，或不太可能引起类似的争议。因此，我们暂时没有进一步推进错误处理的更改。也许未来的某个见解将帮助我们改善现状。
提案
鉴于模块和泛型正在积极开发中，并且错误处理更改暂时搁置，我们还应该寻求哪些其他更改（如果有）？有一些长期以来备受青睐的建议，例如枚举和不可变类型的请求，但这些想法都没有得到充分的发展，也不够紧急，不足以引起 Go 团队的过多关注，尤其是在考虑进行语言更改的成本时。
在审查了所有可能可行的提案之后，更重要的是，因为我们不希望在没有长期计划的情况下增量添加新功能，我们认为这次最好暂停重大更改。相反，我们专注于几个新的 vet 检查和对语言进行微调。我们选择了以下三个提案
#32479. 在 go vet 中诊断 string(int) 转换。
我们原计划在即将发布的 Go 1.14 版本中完成此项工作，但未能实现，所以现在再次提出。string(int) 转换在 Go 早期为了方便而引入，但对于新手来说会引起困惑（string(10) 是 "\n" 而不是 "10"），并且鉴于现在 unicode/utf8 包中提供了此转换，它已不再有必要。由于移除此转换不是向后兼容的更改，我们建议先从 vet 错误开始。
#4483. 在 go vet 中诊断不可能的接口-接口类型断言。
目前，Go 允许任何类型断言 x.(T)（以及相应的类型 switch case），其中 x 和 T 的类型都是接口。然而，如果 x 和 T 都有一个同名但签名不同的方法，那么赋给 x 的任何值都不可能同时实现 T；这样的类型断言在运行时将始终失败（导致 panic 或求值为 false）。既然我们在编译时就已知晓这一点，编译器不妨直接报告错误。在这种情况下报告编译器错误不是向后兼容的更改，因此我们也建议先从 vet 错误开始。
#28591. 对带有常量字符串和索引的索引和切片表达式进行常量求值。
目前，使用常量索引或多个索引对常量字符串进行索引或切片，会分别产生非常量 byte 或 string 值。但如果所有操作数都是常量，编译器可以对这些表达式进行常量求值，并产生一个常量（可能是无类型）结果。这是一个完全向后兼容的更改，我们建议对规范和编译器进行必要的调整。
(更正：发布后我们发现此更改并非向后兼容；详情请参阅评论。)
时间表
我们认为这三个提案都不存在争议，但总有可能我们遗漏了重要内容。因此，我们计划在 Go 1.15 发布周期开始时（在 Go 1.14 发布时或发布后不久）实施这些提案，以便有充足的时间收集经验和提供反馈。根据提案评估流程，最终决定将在开发周期结束时，即 2020 年 5 月初做出。
还有一件事…
我们收到的语言更改提案（标有 LanguageChange 标签的 issue）比我们能够彻底审查的数量要多得多。例如，仅错误处理一项，就有 57 个 issue，其中 5 个目前仍然开放。由于进行语言更改的成本很高，无论更改多小，而且好处往往不明确，我们必须小心谨慎。因此，大多数语言更改提案迟早会被拒绝，有时只提供最少的反馈。这对于所有相关方来说都是不满意的。如果您花费了大量时间和精力详细阐述您的想法，那么不立即被拒绝会是件好事。另一方面，由于通用的提案流程故意设计得很简单，因此很容易创建那些只进行了边缘探索的语言更改提案，这给审查委员会带来了大量工作。为了改善每个人的体验，我们为语言更改添加了一个新的问卷：填写该模板将帮助审查人员更有效地评估提案，因为他们无需自己尝试回答这些问题。并且希望它还能通过从一开始就设定预期，为提案者提供更好的指导。这是一项实验，我们将根据需要随着时间进行完善。
感谢您帮助我们改进 Go 的使用体验！
下一篇文章：pkg.go.dev 的下一步
上一篇文章：宣布 2019 年 Go 开发者调查结果
博客索引