:::info 日期：2020 年 01 月 28 日
作者：Robert Griesemer, for the Go team
原文链接：https://go.dev/blog/go1.15-proposals :::

状态

我们接近 Go 1.14 版本，计划在 2 月份发布，假设一切顺利，RC1 候选版本几乎准备就绪。 根据 Go 2 中概述的过程，我们来了！ 博客文章，在我们的开发和发布周期中，又到了考虑是否以及我们可能希望在今年 8 月发布的下一个版本 Go 1.15 中包含哪些语言或库更改的时候了。

Go 的主要目标仍然是包和版本管理、更好的错误处理支持和泛型。 模块支持状况良好并且每天都在变得更好，我们也在泛型方面取得进展（今年晚些时候会有更多）。 七个月前，我们尝试提供更好的错误处理机制，即 try 提议，得到了很好的支持，但也遭到了强烈反对，我们决定放弃它。 在其之后，有许多后续提案，但似乎没有一个足够令人信服，显然优于 try 提案，或者不太可能引起类似的争议。 因此，我们暂时没有进一步对错误处理进行更改。 也许未来的一些见解将帮助我们改善现状。

提案

考虑到模块和泛型正在积极开发中，并且暂时排除了错误处理更改，我们还应该追求哪些其他更改（如果有）？ 有一些永恒的最爱，例如对枚举和不可变类型的请求，但这些想法都还没有得到充分发展，也不够紧迫，需要 Go 团队给予大量关注，尤其是在考虑开发语言改变的成本时。

在审查了所有可能可行的提案后，更重要的是，由于我们不想在没有长期计划的情况下逐步添加新功能，因此我们得出的结论是，这次最好暂缓进行重大更改。 相反，我们专注于一些新的 vet 审查和对语言的小幅调整。 我们选择了以下三个提案：

  1. [#32479](https://golang.org/issue/32479)。 在 go vet 中诊断 string(int) 转换。 我们计划在即将发布的 Go 1.14 版本中完成这项工作，但我们没有解决，所以又来了。 为了方便起见，在 Go 的早期引入了 string(int) 转换，但它让新手感到困惑（string(10) 是“\n”而不是“10”）并且现在不再证明这种转换在 unicode/utf8 中可用。 由于[删除此转换](https://golang.org/issue/3939)不是向后兼容的更改，因此我们建议从 vet 错误开始。

#4483。 在 go vet 中诊断不可能的接口-接口类型断言。 目前，Go 允许任何类型断言 x.(T)（以及相应的类型 switch case），其中 x 和 T 的类型是接口。 然而，如果 x 和 T 都有一个名称相同但签名不同的方法，则分配给 x 的任何值都不可能也实现 T； 这样的类型断言在运行时总是会失败（恐慌或评估为假）。 既然我们在编译时就知道这一点，那么编译器也可能会报错。 在这种情况下报告编译器错误不是向后兼容的更改，因此我们还建议从 vet 错误开始。

#28591。 使用常量字符串和索引对索引和切片表达式进行常量评估。 目前，使用一个或多个常量索引对常量字符串进行索引或切片会分别产生一个非常量字节或字符串值。 但是如果所有操作数都是常量，编译器可以对这些表达式进行常量求值并产生一个常量（可能是无类型的）结果。 这是一个完全向后兼容的更改，我们建议对规范和编译器进行必要的调整。 （更正：我们在发布后发现此更改不向后兼容；有关详细信息，请参阅评论。）

时间轴

我们相信这三个提案中没有一个是有争议的，但我们总是有可能错过一些重要的事情。 出于这个原因，我们计划在 Go 1.15 发布周期开始时（在 Go 1.14 发布时或之后不久）实施这些建议，以便有足够的时间来收集经验并提供反馈。 根据提案评估过程，最终决定将在开发周期结束时，即 2020 年 5 月开始。

还有一点

我们收到的语言更改建议（标记为 LanguageChange 的问题）多于我们可以彻底审查的数量。 例如，仅就错误处理而言，就有 57 个问题，其中 5 个目前尚未解决。 由于进行语言更改的成本，无论多小，都很高，而且收益往往不明确，因此我们必须谨慎行事。 因此，大多数语言更改提案迟早会被拒绝，有时反馈很少。 这让所有相关方都不满意。 如果您花费大量时间和精力详细概述您的想法，最好不要立即拒绝它。 另一方面，由于一般的提案过程故意简单，因此很容易创建仅进行少量探索的语言更改提案，从而导致审查委员会进行大量工作。 为了改善每个人的这种体验，我们添加了一个新的语言更改问卷：填写该模板将帮助审阅者更有效地评估提案，因为他们不需要自己尝试回答这些问题。 希望它还可以通过从一开始就设定期望，为提议者提供更好的指导。 这是一个实验，我们将根据需要随着时间的推移进行改进。

感谢您帮助我们改善 Go 体验！