Go 博客
Go 1.15 的提案
状态
Go 1.14 版本发布在即，计划于二月份发布（一切顺利的话），RC1 候选版本已基本准备就绪。根据 “Go 2, here we come!” 博文所述的流程，现在到了我们开发和发布周期中考虑是否以及将哪些语言或库更改纳入我们下一个版本 Go 1.15 的时候了，该版本计划于今年八月发布。
Go 的主要目标仍然是包和版本管理、更好的错误处理支持以及泛型。模块支持目前状况良好，并且与日俱进，我们在泛型方面也取得了进展（稍后会详细介绍）。七个月前，我们尝试提供一种更好的错误处理机制，即 try 提案，虽然获得了很好的支持，但也遭到了强烈的反对，我们最终决定放弃它。在此之后，涌现了许多后续提案，但没有一个提案足够有说服力，明显优于 try 提案，或不太可能引起类似的争议。因此，目前我们暂时没有进一步推进错误处理的更改。也许未来的某个见解能帮助我们改进现状。
Proposals
鉴于模块和泛型正在积极开发中，并且暂时搁置了错误处理的更改，我们还应该追求哪些其他更改（如果有的话）？有一些长年累月的热门请求，例如枚举类型和不可变类型，但这些想法都还没有足够成熟，也没有紧迫到需要 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)（以及相应的类型开关 case），其中 x 和 T 的类型都是接口。然而，如果 x 和 T 都有一个同名但签名不同的方法，那么任何赋给 x 的值都不可能同时实现 T；此类类型断言总会在运行时失败（恐慌或评估为 false）。由于我们可以在编译时知道这一点，编译器可以报告一个错误。在此情况下报告编译器错误不是一个向后兼容的更改，因此我们也建议首先从 vet 错误开始。
#28591。使用常量字符串和索引常量地求值索引和切片表达式。
目前，使用常量索引或索引对常量字符串进行索引或切片，会分别产生一个非常量 byte 或 string 值。但是，如果所有操作数都是常量的，编译器就可以常量地求值这些表达式并产生一个常量（可能是未类型化的）结果。这是一个完全向后兼容的更改，我们建议对规范和编译器进行必要的调整。
（更正：发布后我们发现此更改不是向后兼容的；有关详细信息，请参见 评论。）
时间线
我们认为这三个提案都并非争议性，但总有可能我们遗漏了什么重要的事情。因此，我们计划在 Go 1.15 发布周期的开始（在 Go 1.14 发布时或之后不久）实施这些提案，以便有充足的时间收集经验并提供反馈。根据 提案评估流程，最终决定将在开发周期结束时，即 2020 年 5 月初做出。
还有一件事……
我们收到的语言更改提案（标记为 LanguageChange 的 issue）比我们能彻底审查的要多得多。例如，仅错误处理一项，就有 57 个 issue，其中五个目前仍处于开放状态。由于语言更改的成本很高（无论多么微小），而收益常常不明确，我们必须谨慎行事。因此，大多数语言更改提案最终都会被拒绝，有时甚至反馈很少。这对于所有相关方来说都是不令人满意。如果您花费了大量时间和精力详细阐述您的想法，那么不希望它被立即拒绝。另一方面，由于通用的 提案流程 非常简单，很容易创建仅进行了少量探索的语言更改提案，这会给审查委员会带来大量工作。为了改善每个人的体验，我们正在为语言更改添加一个新的 问卷：填写该模板将有助于审阅者更有效地评估提案，因为他们无需自己回答这些问题。并希望它能通过从一开始就设定预期，为提案者提供更好的指导。这是一个我们将根据需要随时间推移进行改进的实验。
感谢您帮助我们改进 Go 的体验！
下一篇文章：pkg.go.dev 的后续步骤
上一篇文章：宣布 2019 年 Go 开发者调查
博客索引