Go 2 之前的一些计划
Robert Griesemer,为了 Go team
26 June 2019
情况#
发布 Go 1.13 的计划进行得很好,很有可能在今年八月就能成功发布了。在长久暂停对语言的变动之后,首次的发布包含具体的语言变动(而不是对语言说明进行小小的改动)。
为了实现这些语言变动,我们从一小撮有望成功的提案出发,从一个远比 Go 2 提案 要大得多的列表之中选择提案。提案的逐条评估大致在博文 “Go 2,我们来了” 中记录。我们希望我们对提案进行的首轮挑选得到的是相对少数、基本无争议的提案,这样这些提案就有比较高的概率在整个工作流程之中存活下来。由于 modules 的出现,提案之中的变化必须向后兼容以最小化混乱,因为 modules 最终会允许指定语言版本,虽然 modules 暂时还不是默认的编译模式。简言之,变动的初始回合主要是为了再次让语言计划动起来同时为新的发展积累经验,而不是啃一些大骨头。
我们的 原始提案列表 —— 通用码标识符、二进制整数字面量、数字字面值分隔符、带符号数字作为移位操作数 —— 既有删减也有增加。由于没有及时得到具体的设计文档,通用码标识符提案没有满足要求。而二进制整数字面量提案有了重要的扩展,并且最终发展成了全面的大整修和 Go 语言数字语法 的现代化。此外我们向 Go 2 设计草案之中加入了 已被部分接受 的关于 错误检视 的部分。
Go 1.13 这些初始的变动就位之后,就到了期待 Go 1.14 和决定如何迈出下一步的时候了。
Go 1.14 提案#
目前 Go 的目标和 2007 年相同: 扩大软件开发规模。目前遇到的三个大的问题就是包版本管理、更好错误处理机制以及泛型。
随着 Go 模块支持越来越强大,我们逐步解决了对包版本管理的支持。对于剩下的错误处理机制和泛型,我们一直在尝试解决,在去年科罗拉多州丹佛市举行的 GopherCon 上我们展示了相关的 设计稿 并一直迭代。 对于错误处理机制,我们发布了一个非常具体的、经过多次审定修改和简化的一个提案(见下文);对于泛型,我们正在努力解决这个问题,在今年圣地亚哥的 GopherCon 上,我们即将发表题目为「 Go 泛型 - Ian Lance Taylor 」的演讲 ,但是还没有具体的提案。
我们也希望继续完成一些小的改进,对于 Go 1.14 版本,我们选择了以下提案:
#32437 内置的 Go 错误检查函数「try」(设计文档)
这是我们改进错误处理的具体的提案,虽然缺乏一定的向后兼容性,但是我们希望通过这个提案可以大大改善进行错误处理所需的成本。这个提案吸引了众多开发的争论,如果你想去了解这个过程可以有点难度。因此,你可以从最早的 初步意见稿 开始快速浏览,然后在去看详细的设计文档。 初步意见稿包含几个链接,指向最新的反馈摘要。提交反馈之前请遵循反馈建议(请参阅下文中的「后续步骤」)。
这是一个早期提交的提案,可以向后兼容,接口嵌套的限制更少。
#32479 在 go vet
中检查 string(int)
类型转换
为了方便起见,string(int)
转换是在 Go 的早期引入的,但是它使新来的用户感到困惑 (string(10)
是 “。”“
不是 “10” ),由于转换可以在
unicode / utf8 包中进行,因此不再合理。由于删除此转换不是向后兼容的更改,因此我们建议从
vet ` 错误开始。
这是对我们希望采用的一组密码库设计原则的反馈。另请参阅 crypto / tls
中的相关建议删除 SSLv3 支持。
下一步#
我们正在积极征求对所有这些建议的反馈。我们对基于事实的证据特别感兴趣,这些证据说明了为什么提案在实践中可能行不通,或者在设计中可能遗漏了有问题的方面。有说服力的实例来支持提案也非常有帮助。另一方面,仅包含个人意见的评论则难以采取行动:我们可以承认这些意见,但不能以任何建设性的方式加以解决。发布之前,请花时间阅读详细的设计文档以及之前的反馈或反馈摘要。特别是在长时间的讨论中,您的担忧可能已经在先前的评论中提出和讨论。
除非有充分的理由甚至没有根据给定的建议进入实验阶段,否则我们计划在 [Go 1.14 周期] 开始时实施所有这些措施 (golang.org/wiki/Go-Release - 周期)(从 2019 年 8 月开始),以便可以在实践中对其进行评估。根据提案评估流程,最终决定将在开发周期结束时 (从 2019 年 11 月开始) 做出。
感谢您帮助使 Go 语言成为更好的语言!
本译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
推荐文章: