译文 预计在 Go 1.18 中内置泛型

kevin · 2021年10月28日 · 471 次阅读
本帖已被设为精华帖!

Hi,大家好

如果没有意外的严重问题,Go 1.18 将包括对泛型的支持。泛型是 Go 1 发布以来最重要的变化,当然也是我们有史以来最大的一次语言变化。这封邮件稍稍解释了泛型的加入对我们和用户的意义。

任何 Go 的新功能,无论是语言还是库,都带有不确定性:如何使用它的不确定性,如何不使用它的不确定性,以及那些不确定的已经通过了现有的测试的微妙 Bug。泛型也不能避免这种不确定性;事实上,因为它是一个大型的新功能,所以不确定性也相应的更大。

因为我们不知道使用泛型的最佳实践是什么,所以我们的文档将无法就何时使用泛型和何时不使用泛型给出清晰明确的答案。我们仍然可以并将给出粗略的指南。作为比较,我们是在不间断地写了一整年的 Go 代码后,才写出了 Effective Go 的最初版本。我们在泛型方面还没有同样的经验,所以我们当然会提供关于如何使用泛型的文档,但我们不能提供任何关于风格和最佳实践的规范。因为我们目前还不了解他们。

因为我们不知道编写泛型包的最佳实践是什么,所以我们发布的最初的泛型代码 -- 特别是通过提案程序的 maps 和 slices 包 -- 将首先落在 golang.org/x/exp 中,并且不保证向后兼容。一旦我们有了更多的经验,我们希望能将其中一些包移入标准库中。比较特别的是 constraints 包,它是编写某些通用代码的基础,将在 Go 1.18 中被添加到标准库中。

因为我们目前没有任何关于泛型的生产实践经验,所以我们会在发布说明中明确指出,在生产中使用泛型的时候应该适当谨慎。这并不是对团队出色工作的批评。这只是因为泛型与大多数 Go 的变化不同。不便于观察。当我们重写垃圾收集器或改变调用约定时,我们会在 Google 的测试和生产中使用新的实现来运行所有 Go 程序,这样就能很好地实践变化并发现难以发现的 Bug。相比之下,用正在进行中的 Go 1.18 工具链重新构建非泛型代码并没有实践对泛型的支持,这意味着我们无法建立同样的信心。

综上所述,Go 1.18 与其他 Go 1.x 版本一样具有向后兼容的承诺:我们不会破坏用 Go 1.18 构建的代码,包括使用泛型的代码。在最坏的情况下,如果我们发现 Go 1.18 的语义有一些致命的问题,并需要改变它们(例如在 Go 1.19 中),我们将使用 go.mod 文件的 go 行来确定该模块中的源文件是期待 Go 1.18 还是 Go 1.19+ 语义。(我们希望不这样做!)

我们预计一些包的作者会急于采用泛型。如果您正在更新您的软件包以使用泛型,请考虑将新的泛型 API 隔离在自己的文件中,并为 Go 1.18 构建标记(//go:build go1.18),以便 Go 1.17 用户可以继续构建和使用非泛型部分。

同样值得注意的是,第三方工具可能不会在 Go 1.18 发布时完全支持泛型。我们正在与许多工具的作者交谈,并试图确保他们得到适当的更新,但各个工具都有自己的时间表。

我们收到的一个常见的问题是:考虑到所有这些不确定性,为什么不把泛型变成可选使用?答案是,在这一点上,减少不确定性的唯一方法是让泛型默认可用。当我们在 Go1.5 版本中让 vendoring 功能变成可选使用时,当时几乎没有人真正使用它,直到 Go1.6 版本默认开启它。所以 Go1.5 版本没有减少 vendoring 功能作用的不确定性。另一方面,Go 1.5 版本无疑将生态系统分为 "在标准 Go 下运行的代码 "和 "在启用 Vendoring 后运行的代码"。我们希望这次尽可能地避免这种结果。

这里每个人可以做的最重要的事情就是写一些通用代码,如果你发现了 bug,不清楚的编译器错误等等,请让我们知道。我最近写了一些通用数据结构,对整体的体验非常满意。我希望你也会这样;如果没有,请提交 bug。谢谢!

Best, Russ

原文地址: https://groups.google.com/g/golang-dev/c/iuB22_G9Kbo/m/7B1jd1I3BQAJ

更多原创文章干货分享,请关注公众号
  • 加微信实战群请加微信(注明:实战群):gocnio
astaxie 将本帖设为了精华贴 10月28日 13:03
ningxiaofang1o GoCN 每日新闻 (2021-10-30) 中提及了此贴 10月30日 05:37
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册