Go 2 计划

本文为官方 Go Blog 的中文翻译，详见 翻译说明

罗伯特·格里塞默
2018年11月29日

背景

在GopherCon 2017上，Russ Cox的演讲正式发布了下一个大型Go语言的思考过程。Go的未来(blog post)。我们已经非正式地将这种未来语言称为Go 2，尽管我们现在知道它将以渐进方式逐步实现，而不是一声巨响和一个主要版本。尽管如此，Go 2还是一个有用的绰号，即使它只是一种谈论未来语言的方式，所以让我们现在继续使用它。

Go 1和Go 2之间的主要区别在于谁将影响设计以及如何制定决策。 Go 1是一个小团队努力，外界影响不大。 Go 2将更加受社区驱动。经过将近10年的接触，我们从一开始就学到了很多关于语言和库的知识，而这只有通过Go社区的反馈才能实现。

2015年，我们引入了提案流程来收集特定的反馈意见：有关语言和图书馆更改的提案。由围棋高级团队成员组成的委员会已在定期审查，分类和决定收到的提案。效果很好，但是作为该过程的一部分，我们忽略了所有不向后兼容的建议，只是将它们标记为Go 2。在2017年，我们也停止了进行任何形式的向后兼容的增量语言更改(无论大小如何)，而是采用了更全面的计划，该计划考虑了Go 2的整体情况。

现在是时候应对Go 2提案了，但是要做到这一点，我们首先需要一个计划。

状态

在撰写本文时，大约有120个标记为Go 2天未解决的问题。它们每一个都提出了一个重大的库或语言更改，通常不满足现有的Go 1兼容性保证。Ian Lance Taylor和我一直在研究这些建议并将其归类(Go2Cleanup，NeedsDecision, 等)，以了解其中的内容并使其更容易运行。我们还合并了相关提案，并关闭了那些显然不在Go范围内，或无法采取行动的提案。

其余提案中的想法可能会影响Go 2的库和语言。早期出现了两个主要的主题：对更好的错误处理的支持，以及泛型。这两个领域的草稿设计已在今年的GopherCon上发布，需要进行更多的探索。

但是其余的呢？由于我们现在拥有数百万的Go程序员和大量的Go代码，我们是受到约束的，我们需要一直坚持下去，以免我们冒分裂生态系统的风险。这意味着我们不能进行很多更改，而我们将要进行的更改必须谨慎选择。为了取得进展，我们正在针对这些重大潜在变化实施新的提案评估流程。

提案评估流程

提案评估过程的目的是收集有关少量选定提案的反馈，以便可以做出最终决定。该过程或多或少与发布周期并行运行，并且包含以下步骤：

1. 提案选择。 Go团队选择了少量的[Go 2提案](github.com/golang/go/issues?utf8=%... ％3AProposal)似乎值得考虑接受，而无需做出最终决定。有关选择标准的更多信息，请参见下文。

2. 提案反馈。 Go小组会发出公告，列出选定的提案。该公告向社区说明了推进所选提案并收集每个提案的反馈的初步意图。这使社区有机会提出建议并表达关注。

3. 实施。基于该反馈，提案得以实施。这些重大的语言和库更改的目标是让它们准备在即将到来的发行周期的第一天提交。

4. 实施反馈。在开发周期中，Go团队和社区有机会尝试这些新功能并收集更多反馈。

5. 启动决定。在三个月的[开发周期]结束时(github.com/golang/go/wiki/Go-Relea...。

通过两轮反馈，该过程倾向于减少建议，这将有望防止功能蠕变并有助于保持语言的小巧和简洁。

对于每个公开的Go 2提案，我们都无法完成此过程，因为提案太多了。这就是选择标准的作用。

提案选择标准

提案至少必须：

1. 解决许多人的重要问题，

2. 对其他人的影响最小，并且

3. 提供清晰易懂的解决方案。

要求1确保我们所做的任何更改都尽可能地帮助Go开发人员(使他们的代码更健壮，更易于编写，更可能正确，等等)，而要求2确保我们小心谨慎地伤害尽可能少的开发人员。可能是通过破坏程序或引起其他流失来实现的。根据经验，我们应该致力于为给定变更带来至少十倍于我们所受伤害的开发人员。不会影响实际Go使用率的更改会带来零净收益，并带来可观的实施成本，因此应避免使用。

没有要求3，我们就无法实施该提案。例如，我们认为某种形式的通用性可能会解决很多人的重要问题，但是我们还没有一个清晰易懂的解决方案。很好，这只是意味着该提案需要先考虑一下才能被考虑。

提案

我们认为这是一个很好的计划，应该对我们有好处，但重要的是要了解这只是一个起点。随着该流程的使用，我们将发现它无法正常工作的方式，并将根据需要对其进行优化。关键的地方是，除非在实践中使用它，否则我们将不知道如何对其进行改进。

一个安全的起点是使用少量向后兼容的语言提案。我们已经很长时间没有进行语言更改了，因此这是我们回到了该模式。而且，这些更改无需我们担心破坏现有代码，因此它们可以作为完美的试用气球。

综上所述，我们建议为Go 1.13版本选择以下Go 2提案（提案评估流程的第1步）：

1. #20706 基于Unicode TR31的常规Unicode标识符：这解决了使用非西方字母的Go程序员的一个重要问题，对其他人影响不大。我们需要回答一些规范化问题，并且在这些问题上社区反馈很重要，但是在此之后，实现路径已经广为人知。请注意，标识符导出规则不受此影响。

2. #19308, #28493 二进制整数直接量和数字直接量中支持for_: 这些是相对较小的更改，在许多程序员中似乎非常受欢迎。它们可能还没有达到解决“重要问题”的门槛（到目前为止，十六进制数字工作得很好），但是在这方面它们使Go与大多数语言并驾齐驱，并减轻了一些程序员的痛苦。它们对不关心二进制整数直接量或数字格式化的其他人影响极小，并且其实现已经广为人知。

3. #19113 允许带符号整数作为shift计数: 估计所有非恒定shifts中有38%需要一个（人工的）unit转化（有关详细信息，请参见这个issue）。该建议将清理大量代码，使shift表达式与索引表达式以及内置函数cap和len更好的同步。这将对代码产生积极影响。该实现是广为人知的。

下一步

通过此博客文章，我们已经执行了提案评估过程的第一步，并开始了第二步。现在，取决于你们——Go社区，来就上述这些问题提供反馈。

对于我们有明确和批准反馈的提案，我们将继续执行（流程中的第3步）。因为我们希望在下一个发布周期的第一天（暂定为2019年2月1日）实施更改，所以我们可能会在此时间提早开始实施，以留出两个月的反馈时间(2018年12月，2019年1月) 。

在为期3个月的开发周期(2019年2月至2019年5月)中，所选功能已实现并可以立即获得，每个人都将有机会收集使用它们的经验。这为反馈提供了另一个机会(流程中的步骤4)。

最终，在repo冻结之后不久（2019年5月1日），Go团队做出最终决定是永久保留新功能（并将其包含在Go 1兼容性保证中），还是放弃它们（流程中的最后一步）。

（由于很有可能在刚冻结repo时就要删除某个功能，因此实现必须确保在不破坏系统其余部分的情况下可以禁用该功能。对于语言更改，这可能意味着所有与功能相关的代码均有内部标志保卫。）

这将是我们第一次遵循此流程，因此冻结repo也将是反思该流程并在必要时候进行调整的好时机。让我们看看进展如何。

评估愉快！

本译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://learnku.com/docs/go-blog/go2-her...

译文地址：https://learnku.com/docs/go-blog/go2-her...