Go 博客
Go 1.15 提案
状态
我们即将发布 Go 1.14，如果一切顺利，计划于 2 月发布，RC1 候选版本几乎已准备就绪。根据 Go 2，我们来了！ 博客文章中概述的过程，在我们开发和发布周期中，再次到了考虑是否以及我们可能希望将哪些语言或库更改包含到我们的下一个版本 Go 1.15 中的时候，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)（以及相应的类型开关 case），其中 x 和 T 的类型都是接口。但是，如果 x 和 T 都有一个名称相同但签名不同的方法，则分配给 x 的任何值都不可能也实现 T；此类类型断言始终会在运行时失败（panic 或计算结果为 false）。由于我们在编译时就知道这一点，因此编译器也可以报告错误。在这种情况下报告编译器错误不是向后兼容的更改，因此我们也建议改为从 vet 错误开始。
#28591。使用常量字符串和索引对索引和切片表达式进行常量求值。
目前，使用常量索引或索引对常量字符串进行索引或切片会分别产生非常量的 byte 或 string 值。但是，如果所有操作数都是常量，则编译器可以对这些表达式进行常量求值并产生常量（可能是未类型化的）结果。这是一个完全向后兼容的更改，我们建议对规范和编译器进行必要的调整。
（更正：我们发布后发现此更改不向后兼容；有关详细信息，请参阅 注释。）
时间线
我们认为这三个提案都不存在争议，但总有可能我们遗漏了一些重要内容。因此，我们计划在 Go 1.15 发布周期的开始（在 Go 1.14 发布时或之后不久）实现这些提案，以便有足够的时间积累经验并提供反馈。根据 提案评估流程，最终决定将在开发周期的结束，即 2020 年 5 月初做出。
还有一件事……
我们收到的语言更改提案（标记为 LanguageChange 的问题）比我们能够彻底审查的多。例如，仅针对错误处理，就有 57 个问题，其中 5 个目前仍在开放状态。由于进行语言更改的成本，无论多么小，都很高，而好处往往不明确，因此我们必须谨慎行事。因此，大多数语言更改提案迟早都会被拒绝，有时甚至没有提供最少的反馈。这对所有相关方来说都是不令人满意的。如果您花费大量时间和精力详细阐述您的想法，那么最好不要立即被拒绝。另一方面，因为一般的 提案流程 故意很简单，所以创建仅经过粗略探索的语言更改提案非常容易，这会导致审查委员会大量的工作。为了改善每个人的体验，我们正在为语言更改添加新的 问卷：填写该模板将帮助审阅者更有效地评估提案，因为他们不需要自己尝试回答这些问题。希望它还能通过从一开始就设定期望来为提案者提供更好的指导。这是一个实验，我们将根据需要随着时间的推移对其进行改进。
感谢您帮助我们改善 Go 体验！
下一篇文章：pkg.go.dev 的下一步
上一篇文章：宣布 2019 年 Go 开发人员调查
博客索引