令人激动！Go 泛型代码合入 Master

master 分支对应了 Go1.17 的版本。因此未来将可以在 Go1.17 使用到泛型，这是一个比较惊喜的事情。

原因

这件事情为什么会突然发生呢?一切都得从背景说起。原本 Go 泛型是一直在 dev.typeparams 分支上进行研讨和开发。

由于泛型不是简单的一两个模块的代码变更，而是涉及大量的代码变更。

因此需要经常保持与 master 分支的代码同步(近两个月共 20+ 次)，会涉及代码冲突/合并的处理。

且对于一些冲突的模块他们也不熟悉(很熟悉的感觉有没有)，所以期望迁移到 master 分支上进行开发。

如何不影响既有功能

这类提前放入主版本的操作，在 Go 语言中并不少见。像是现在所见的 GO111MODULE，早期的GO15VENDOREXPERIMENT 都有些这么个味道。都是逐步入场，分阶段使用，等确定成熟、完善后再渐渐去掉。

因此本次泛型也采取了这种方法，按照提案，目前使用的是 -G 标识做为泛型的开关。

计划如下：

• -G=0：继续使用传统的类型检查器。
• -G=1：使用 type2，但不支持泛型。
• -G=2：使用 type2，支持泛型。

在完成 types2 的错误和现有的错误的开发协调后，计划在 Go 1.17 将 -G=1 设置为默认值。

未来也许可以在 Go 1.18 中放弃对 -G=0 的支持，这样后续在默认启用 -G=2 上会变得更容易。

在 Go1.17 尝鲜

在 Go1.17 尝鲜，也就意味着需要拉取 Go 语言的 master 分支的代码，Go1.17 现在正处于开发阶段：提了 CL 变更，只是代码冲突了，待解决。

总结

Go 语言的泛型开发计划已经比较明确。首先合入 master 分支，再逐步完成开发，逐步开放。

再进行 -G 默认值的调整，最后在泛型完善后就默认开启，把 -G 标识彻底去掉。

细品，与 Go modules 的方向是不是差不多。一开始 GO111MODULE 需要手动开启 on(也就是默认 off)，再到 Go1.16 GO111MODULE 默认为 on。

以此完成了一个正反馈的循环，逐步开放，接受社区反馈和开发调整。

（编辑：张家口站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!