大家好，我是程序员幽灵。前段时间，RobPike在Go的repo中提出了一个问题：go:don'tchangethelibrariesin1.18[1]，并提到因为泛型是语言层面的重大变化，所以必须一步一步来，而且步幅不宜过大。详细的介绍可以查看：Goisseriousaboutcompatibility:genericsmustbeaddedslowly。昨天，GoTeamLeaderRussCox在golang-dev邮件组发了一封长邮件：对Go1.18中泛型的期望[2]，说明了Go1.18和泛型目前的进展以及后续的支持策略。确定Go核心团队和社区努力的方向。以下为邮件内容，并非完整翻译。如果没有什么大事发生，Go1.18将包括对泛型的支持。泛型是自Go1发布以来最重要的变化，当然也是我们做过的最大的语言变化[3]。这封电子邮件解释了包含仿制药对我们和我们的用户意味着什么。任何新的Go特性，无论是在语言层面还是库层面，都伴随着不确定性：关于如何使用它的不确定性，关于如何不使用它的不确定性，以及关于哪些小错误已经通过现有测试的不确定性。当然，泛型的加入也会有这个不确定性。事实上，由于泛型是一个更大的新特性，不确定性也相应地更大。因为我们不知道使用泛型的最佳实践是什么，所以我们的文档将无法就何时使用它们以及何时不使用它们给出准确、明确的答案。当然，我们可以并且仍然会给出使用泛型的粗略指南。事实上，我们之前也做过类似的事情：经过一年不停地编写Go代码，我们编写了EffectiveGo的初始版本[4]。我们在泛型方面也没有丰富的经验，因此虽然我们会提供有关如何使用它们的文档，但我们无法提供有关编码风格和最佳实践的任何说明。因为我们不知道编写泛型包的最佳实践是什么，所以原本计划专门为泛型发布的包映射和切片不会进入标准库，而是先放到golang.org/x/exp[5]，这里的代码不保证向后兼容。一旦我们有了更多的经验，我们希望将其中一些包添加到标准库中。然而，constraints包将按预期进入Go1.18的标准库，因为它是编写一些通用代码的基础。由于我们没有任何使用Go泛型的实际经验，我们将在发行说明中明确表示应谨慎处理泛型的生产使用（注意：很有可能您会谨慎而不会立即使用它们）。请注意，这并不是说团队做得不好。毕竟，泛型不同于大多数Go的变化。那时，当我们重写垃圾收集器或更改调用约定时，我们使用新实现在测试和生产中运行所有Google的Go程序，以便我们可以很好地验证更改并捕获难以发现的错误。相比之下，使用仍在开发中的Go1.18工具链重建非泛型代码并不能验证对泛型的支持，这意味着我们无法建立同样的信心。总而言之，Go1.18与其他Go1.x版本具有相同的向后兼容性承诺：我们不会破坏使用Go1.18构建的代码，包括使用泛型的代码。在最坏的情况下，如果我们发现Go1.18语义存在一些致命问题并需要更改它们（例如在Go1.19中），我们将使用go.mod文件的go版本指示来确定模块中的源文件预计Go1.18或Go1.19+语义。（目前，我们不希望需要这样做！）我们希望一些第三方包作者首次采用泛型。如果您正在更新您的包以使用泛型，请考虑将新的通用API分离到它自己的文件中并添加Go1.18构建标签，例如//go:buildgo1.18forGo1.17用户可以继续构建和使用非泛型类型。还值得注意的是，在Go1.18发布时，第三方工具可能无法完全支持泛型。我们正在与许多工具的作者交谈，并试图确保它们得到正确更新，但每个工具都有自己的时间表。不少人向我们提出了一个常见问题：鉴于所有这些不确定性，为什么不在Go1.18中将泛型设为可选？（注：其实Go1.17有一些可选的）其实在这一点上，唯一能减少不确定性的方法就是默认提供泛型。当我们在Go1.5中将vendoring设为可选时，结果发现几乎没有人实际使用它，直到Go1.6才默认打开它。因此，Go1.5版本并没有减少我们对Go开发人员使用vendoring的不确定性。另一方面，在这种情况下，Go1.5版本明确地将生态系统分为“在标准Go下运行的代码”和“在启用vendoring的情况下运行的代码”。我们希望Go1.18尽可能避免这种结果。作为一个Go爱好者，作为一个期待泛型的你，最重要的是写一些泛型代码。如果您发现错误、不清楚的编译器错误等，请提出问题。我最近写了一些通用的数据结构，对整??体体验非常满意。我希望你也这样做;如果您不这么认为，请提出问题。谢谢你！本文转载自微信公众号“有鬼”，可通过以下二维码关注。转载本文请联系有鬼公众号。
