:::info 日期：2019 年 06 月 26 日
作者：Robert Griesemer, for the Go team
原文链接：https://go.dev/blog/go2-next-steps :::

状态

我们正在向 Go 1.13 的发布迈进，希望能在今年 8 月初发布。这是第一个将包括对语言的具体更改（而不仅仅是对规范的微小调整）的版本，在更长的暂停任何此类更改之后。

为了实现这些语言更改，我们根据“Go 2，我们来了！”中概述的新提案评估过程，从更大的 Go 2 提案列表中选择了一小部分可行提案。博客文章。我们希望我们最初选择的提案相对较少，而且大多没有争议，有相当高的机会让它们通过这个过程。提议的更改必须向后兼容才能将破坏性降至最低，因为最终将允许选择特定于模块的语言版本的模块还不是默认的构建模式。简而言之，这轮最初的变革更多是为了让球再次滚动并获得新流程的经验，而不是解决大问题。

我们最初的提案列表——通用 Unicode 标识符、二进制整数文字、数字文字的分隔符、有符号整数移位计数——都得到了修剪和扩展。由于我们没有及时制定具体的设计文档，因此通用 Unicode 标识符没有成功。二进制整数文字的提议得到了显着扩展，并导致了 Go 数字文字语法的全面改革和现代化。并且我们添加了关于错误检查的 Go 2 草案设计提案，该提案已被部分接受。

随着 Go 1.13 的这些初始更改就位，现在是时候期待 Go 1.14 并确定我们接下来要解决的问题了。

Go 1.14 的提案

我们今天对 Go 的目标与 2007 年相同：使软件开发规模化。在这条路上提高 Go 的可扩展性的三个最大障碍是包和版本管理、更好的错误处理支持和泛型。

随着对 Go 模块的支持越来越强大，正在解决对包和版本管理的支持。这留下了更好的错误处理支持和泛型。我们一直在研究这两个方面，并在去年丹佛的 GopherCon 上展示了设计草案。从那时起，我们一直在迭代这些设计。对于错误处理，我们发布了一个具体的、经过重大修改和简化的提案（见下文）。对于泛型，我们正在取得进展，今年在圣地亚哥举行的 GopherCon 上将有一场演讲（Ian Lance Taylor 的“Generics in Go”），但我们还没有达到具体的提案阶段。

我们还希望继续对语言进行较小的改进。对于 Go 1.14，我们选择了以下提案：

#32437。一个内置的 Go 错误检查功能，“try”（设计文档）。

这是我们改进错误处理的具体建议。虽然提议的完全向后兼容的语言扩展很小，但我们预计对错误处理代码的影响很大。这个提议已经引起了大量的评论，跟进并不容易。我们建议从最初的评论开始快速提纲，然后阅读详细的设计文档。最初的评论包含几个指向迄今为止反馈摘要的链接。在发布之前，请遵循反馈建议（请参阅下面的“后续步骤”部分）。

#6977。允许嵌入重叠接口（设计文档）。

这是一个旧的、向后兼容的提议，用于使界面嵌入更宽容。

#32479 在 go vet 中诊断 string(int) 转换。

为了方便起见，在 Go 的早期引入了 string(int) 转换，但它让新手感到困惑（string(10) 是“\n”而不是“10”）并且现在不再证明这种转换在 unicode/utf8 中可用包裹。由于删除此转换不是向后兼容的更改，因此我们建议从 vet 错误开始。

#32466 采用加密原则（设计文档）。

这是对我们希望采用的加密库的一组设计原则的反馈请求。另请参阅从 crypto/tls 中删除 SSLv3 支持的相关提案。

下一步

我们正在积极征求对所有这些建议的反馈。我们对基于事实的证据特别感兴趣，这些证据说明了为什么提案在实践中可能无法很好地发挥作用，或者我们可能在设计中遗漏了一些有问题的方面。支持提案的令人信服的例子也很有帮助。另一方面，仅包含个人意见的评论不太具有可操作性：我们可以承认它们，但我们不能以任何建设性的方式解决它们。在发布之前，请花时间阅读详细的设计文档和之前的反馈或反馈摘要。特别是在长时间的讨论中，您的担忧可能已经在之前的评论中提出和讨论过。

除非有充分的理由甚至不进入给定提案的实验阶段，否则我们计划在 Go 1.14 周期开始时（2019 年 8 月开始）实施所有这些，以便在实践中对其进行评估。根据提案评估流程，最终决定将在开发周期结束时（2019 年 11 月开始）做出。

感谢您帮助 Go 成为一种更好的语言！