前段时间，go 语言之父 rob pike 在 go 代码仓库提交了一个 issue (#48918)，建议不要改动 go 1.18 中的标准库，不要在 1.18 的标准库中使用泛型。
然而昨日，russ cox（go 核心开发团队技术 leader，下简称"rsc"）公开发布邮件，称如果没有意外情况，go 1.18 将会支持泛型。
rsc 表示，泛型是 go 1 发布以来 go 语言最重要的变化，同时也是有史以来最大的单一语言特性变化。他写这封邮件主要是解释为 go 加入泛型对 go 开发团队以及其他开发者的意义。
rsc 认为，go 的任何新特性——无论是库或者语法，都具有不确定性。同样的，泛型也无法避免这种不确定性。而且由于泛型是一个较大的新特性，因此它带来的不确定性也会相应地更大。虽然他们为 go 语言带来了泛型，但他们自己并不了解使用泛型的最佳实践是什么，所以无法在文档给出关于何时使用泛型以及何时不使用的准确、明确答案。
此外，go 团队没有任何在生产环境使用泛型的经验，因此 rsc 表示他们会在发布说明中明确指出，在生产环境中使用泛型应该适当地谨慎处理。
rsc 强调了 go 1.18 与其他 go 1.x 版本一样具有向后兼容的承诺：他们不会破坏使用 go 1.18 构建的代码的兼容性，包括使用泛型的代码。最坏的情况下，如果发现 go 1.18 语义存在致命的问题，并需要进行更改（例如在 go 1.19 中提供更改），他们会使用 go.mod 文件的 go line 来确定该模块中的源文件符合 go 1.18 还是 go 1.19+ 语义（预计不需要使用这种方法）。
rsc 还提到，第三方工具可能不会在 go 1.18 发布时就完全支持泛型。他们正在与许多工具的作者沟通，尽量确保他们尽快更新，但每项工具都有自己的时间安排表。
对于“为什么不把「泛型」作为可选项提供”的疑问，rsc 也进行了解释。他表示，在这方面，减少不确定性的唯一方法是默认提供泛型。rsc 用 vendoring 举例，他表示，当 go 团队在 go 1.5 将 vendoring 作为可选项提供时，发生的情况是几乎没有人真正使用它，直到 go 1.6 默认启用。另一方面，go 1.5 版本将 go 生态分裂成“在标准 go 下运行的代码”和“在启用 vendoring 后 go 运行的代码”。现在他们希望尽可能避免泛型也出现这种情况。
你期待支持泛型的 go 1.18吗？你是否也认为强类型不能没有泛型呢？