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 上展示了 草案设计。从那时起，我们一直在迭代这些设计。对于错误处理，我们已经发布了一个具体且经过大幅修改和简化的提案（见下文）。对于泛型，我们正在取得进展，今年在圣地亚哥举行的 GopherCon 上将有一个关于“Go 中的泛型”（由 Ian Lance Taylor 演讲）的演讲 即将举行，但我们尚未达到具体的提案阶段。
我们还希望继续对语言进行更小的改进。对于 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 商店
上一篇文章：Go 2018 年调查结果
博客索引