Go 博客
迈向 Go 2 的下一步
状态
我们正顺利迈向 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 大会上展示了草案设计。自那时以来，我们一直在迭代这些设计。关于错误处理，我们已经发布了一个具体的、经过显著修订和简化的提案（见下文）。关于泛型，我们正在取得进展，Ian Lance Taylor 将在今年的圣迭戈 GopherCon 大会上发表题为“Go 中的泛型”的演讲，但我们尚未达到具体提案阶段。
我们还希望继续对语言进行一些较小的改进。对于 Go 1.14，我们选择了以下提案
#32437。一个内置的 Go 错误检查函数，“try” (设计文档)。
这是我们改进错误处理的具体提案。尽管提议的、完全向后兼容的语言扩展是最小的，但我们期望它对错误处理代码产生巨大的影响。这个提案已经吸引了大量的评论，而且跟进并不容易。我们建议从初始评论开始快速了解概要，然后阅读详细的设计文档。初始评论包含了一些链接，指向目前为止的反馈摘要。在发帖之前，请遵循反馈建议（参见下文“下一步”部分）。
这是一个旧的、向后兼容的提案，旨在使接口嵌入更加容忍。
#32479 在 go vet 中诊断 string(int) 转换。
早前在 Go 中引入 string(int) 转换是为了方便，但这对于新手来说令人困惑（string(10) 是 "\n" 而不是 "10"），并且现在 unicode/utf8 包中提供了这种转换，因此不再合理。由于移除此转换并非向后兼容的变更，我们建议首先以 vet 错误的形式提示。
这是一项征求对一套我们希望采纳的密码学库设计原则的反馈请求。另请参阅相关的从 crypto/tls 中移除 SSLv3 支持的提案。
下一步
我们正在积极征集对所有这些提案的反馈。我们特别关注基于事实的证据，说明为什么某个提案在实践中可能效果不佳，或者设计中我们可能遗漏的问题方面。支持提案的令人信服的例子也非常有帮助。另一方面，只包含个人意见的评论可操作性较低：我们可以cknowledged它们，但无法以任何建设性的方式加以解决。在发帖之前，请花时间阅读详细的设计文档以及先前的反馈或反馈摘要。尤其是在冗长的讨论中，您关心的问题可能已经在之前的评论中提出并讨论过了。
除非有充分的理由不让某个提案进入实验阶段，否则我们计划在Go 1.14 周期开始时（2019 年 8 月初）实现所有这些提案，以便在实践中进行评估。根据提案评估流程，最终决定将在开发周期结束时（2019 年 11 月初）做出。
感谢您帮助 Go 成为一门更好的语言！
下一篇文章：宣布新的 Go 商店
上一篇文章：Go 2018 年度调查结果
博客索引