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 的演讲“Go 中的泛型”将在今年的圣迭戈 GopherCon 大会上 举行，但我们尚未进入具体的提案阶段。
我们还希望继续对语言进行小型改进。对于 Go 1.14，我们选择了以下提案：
#32437。内置的 Go 错误检查函数，“try”（设计文档）。
这是我们为改进错误处理而提出的具体提案。虽然提出的、完全向后兼容的语言扩展很小，但我们预计它将对错误处理代码产生巨大的影响。该提案已经吸引了大量的评论，并且不容易跟踪。我们建议从 第一个评论 开始快速了解概况，然后阅读详细的设计文档。第一个评论包含几个链接，指向到目前为止的反馈摘要。在发布之前，请遵循反馈建议（见下文的“后续步骤”部分）。
这是一个古老的、向后兼容的提案，旨在使接口嵌入更加容忍。
#32479 在 go vet 中诊断 string(int) 转换。
string(int) 转换在 Go 的早期版本中为了方便而引入，但它会让新用户感到困惑（string(10) 是 "\n" 而不是 "10"），而且现在 unicode/utf8 包中提供了此转换，它已经不再合理。由于删除此转换不是向后兼容的更改，我们建议首先将其作为 vet 错误。
这是对我们希望采用的一组加密库设计原则的反馈请求。另请参阅相关的 从 crypto/tls 中移除 SSLv3 支持的提案。
下一步
我们正在积极征求对所有这些提案的反馈。我们特别感兴趣的是基于事实的证据，说明某个提案在实践中可能无法很好地工作，或者我们可能在设计中遗漏了什么问题。支持某个提案的有说服力的例子也非常有帮助。另一方面，仅包含个人意见的评论可操作性较差：我们可以承认它们，但无法以任何建设性的方式解决它们。在发布之前，请花时间阅读详细的设计文档和先前的反馈或反馈摘要。尤其是在长讨论中，您的担忧可能已经在之前的评论中被提出和讨论过。
除非有强烈的理由反对将某个提案推入实验阶段，否则我们计划在 Go 1.14 周期（2019 年 8 月初）开始时实现所有这些提案，以便它们可以在实践中进行评估。根据 提案评估流程，最终决定将在开发周期结束时（2019 年 11 月初）做出。
感谢您帮助使 Go 成为一个更好的语言！
下一篇文章：宣布新的 Go Store
上一篇文章：Go 2018 调查结果
博客索引