Ian Lance Taylor and Robert Griesemer
2020.7.16

介绍

自从我们最后写关于将范型添加进Go中,过了快一年了,是时候进行一次更新了。

更新后的设计

我们一直在完善范型设计草案。我们已经为它写了一个类型检查器:一个可以解析用了草案描述的范型的Go代码,并报告任意类型的错误。我们已经写好了示例代码。同时,我们从很多很多人那里收集了反馈信息,实在感谢!
基于我们已经学到的,我们发布了一个更新后的设计草案。最大的变化是我们丢弃了合约(constract)的想法。考虑到合约(constract)和接口类型(interface type)之间的差异让人困惑,所以我们消除了这类差异。现在类型参数收到接口类型的约束。接口类型现在被允许包含类型列表,尽管只能在用作约束时候使用。在这之前的设计草案中,类型列表是合约的一个特性。更复杂的例子会使用一个参数化的接口类型。
我们希望大家会发现这个设计草案更简单更容易理解。

体验工具

为了在未来更好的完善设计草案,我们发布了一个翻译工具。这是一个可以让大家使用类型检查、运行用设计草案中描述的范型的代码的工具。它通过翻译范型代码为传统Go代码运行。这个翻译过程会加上一些限制,但是我们希望这样的方式可以足够让大家可以感受范型在Go代码中的样子。如果范型设计被接受进入Go语言规范的话,真正的范型实现会有所不同。(我们只是刚刚构勒出一个直接编译器实现的样子)
这个工具在另一个Go playground提供: https://go2goplay.golang.org 这个playground和之前的playground长的一样,只是支持了范型的代码。
你也可以自己构建和使用这个工具。它在Go仓库的一个分支上提供。可以关注 从源代码安装Go的说明。在这个说明中,会指导你check out最新的发布tag,而不是运行git checkout dev.go2go。然后按照说明构建Go的工具链。
这个翻译工具的文档在 README.go2go.

下一步

我们希望这个工具可以给Go社区一个体验范型的机会。我们希望能了解下面两件事:
首先,范型代码有意义吗?范型的感觉像Go吗?大家会遇到什么怪事吗?错误信息是否有用?
其次,我们知道很多人说过Go需要范型,但是我们并不确定这意味着什么。这个设计草案是否解决了这个问题?是否有一个问题让你觉得:‘如果Go有范型我就能解决它“,你能否用这个工具解决它?
我们会用在Go社区收集的反馈信息决定接下来如何发展。如果设计草案广受好评,并且不需要重大的变动,下一步会成为一个正式的语言变化提案。预期的话,如果每个人都对设计草案非常满意,并且不需要再进行修改,范型加到Go中最早的时间应该是Go 1.17的发布,按照规划应该是2021年八月。但现实总有意外的问题,因此这是一个乐观的时间线,我们不能做出准确的预测。

反馈

提供语言变化反馈的最佳方式是发送邮件给:golang-nuts@googlegroups.com.邮件列表不是最完美的,但是是我们开始讨论的最佳选项。当编写设计草案时,请在主题的开头加上[generics],并针对不同的主题开始不同的邮件。
如果你找到了范型类型检查器或翻译工具的bug,它们应该被提到标准Go issue,由https://golang.org/issue进行跟踪。issue的开头请用cmd/go2go;需要注意的是,issue跟踪器并不是讨论语言变化最好的地方,因为它不提供长时间的对话流程。
我们期待你们的反馈信息。

致谢

我们没有结束,我们会携手同行很长一段时间。如果没有大家帮助,我们不会走到现在。
我们感谢Philip Wadler和他的合作者,他们正式考虑了Go中的范型,然后帮助我们理清了理论设计。他们的论文 Featherweight Go 分析了Go严格版本的范型,并开发了一个原型,地址在GitHub。
同时也感谢那些,在早期设计版本中就给我们详细反馈的人们。
最后,感谢Go团队的许多人,很多贡献者,每个人在设计草案中都分享了他们的观点和反馈。我们阅读了所有的反馈,我们非常感激,如果没有你们,我们不能走到现在。