Go 泛型变更：约束太丑了，先移动到 x/exp 做实验性功能

大家好，我是煎鱼。

Go 泛型配套了各种标准库，像是常见的 maps、slices 泛型库。

早期他们是长这样的：

package maps

func Keys[M constraints.Map[K, V], K comparable, V any](m M) []K

func Values[M constraints.Map[K, V], K comparable, V any](m M) []V
...

又或是：

package slices

func Compare[E constraints.Ordered](s1, s2 []E) int 
...

关注到里面的标准库 constraints，他就是今天变更的主角。他咋了呢？

背景

标准库 constraints 是个新鲜事物，由泛型扛把子 Ian Lance Taylor 在 2021 年 9 月 24 日提交《constraints: new package to define standard type parameter constraints》 所添加。

如下图：

主要作用是添加一个约束（constraints）包来定义一些标准有用的约束，所以我们会在通用库看到这些标准约束的使用。

缘由

新提案

在社区一番热烈讨论中，有人提了一个提案《proposal: constraints: rename package to "of"》，希望对 constraints 包进行更名。

新的代码如下：

func Abs[V of.Number](v V) V{...}

func Sum[K comparable, V of.Number](m map[K]V) V {...}

作者认为使用 “of” 这个关键字比 “constraints” 更简单流畅。

该提案引来了大量的讨论，觉得 constraints 这个名字现在太长，一旦函数签名比较多，就会很繁琐，看着也不舒服。

有建议使用引用别名来解决的：

import of “constraints”

也有说是用 any，is 名字，甚至叫 std，或是其他的导入方式。

众说纷纭，虽然在后面大幅度的优化了 constraints 的使用频率，但一旦用到 2~3 次，就会出现函数签名过于庞大的问题。

最终由于未能讨论出明确的共识，被拒绝。

挣扎的结论

经过这长时间的泛型推进和命名争议，Russ Cox 发现约束包仍然存在着许多问题，是待商榷的。

分别是：

• 包名字太丑：很多人对包的名字，也就是对 constraints 很满意，也有很不满意的，觉得太长，太啰嗦。

• 不知道放什么：对于放在包里面的东西，尚不清楚哪些接口是重要的，应该存在，哪些不应该存在。

• 似乎不需要：一开始认为标准的约束是使用泛型的基础，但在实践中并没有证明是这样，甚至可以不要。

基于上述原因，Go 团队决定将标准库 constraints 与 maps、slices 一样，转移到 x/exp 中，作为实验性功能来对待。

再在 Go 1.19 或 1.20 中重新审视他们，看看是不是真的有用，又或是怎么用才是对的，再做决定。

总结

Go 泛型在本月（2月）即将在 Go1.18 中发布（春节的时候，通知社区鸽到 3 月份了...），虽然从表面来看，核心功能已经基本定型了，但配套设施还是比较乱。

建议大家在正式生产使用上，还是有注意节奏，免得踩坑。

你觉得 constraints 这个命名咋样，欢迎大家一起来讨论：）

参考

• proposal: constraints: move to x/exp for Go 1.18

• proposal: constraints: rename package to "of"

关注煎鱼，获取业内第一手消息和知识 👇

你好，我是煎鱼，出版过 Go 畅销书《Go 语言编程之旅》，再到获得 GOP（Go 领域最有观点专家）荣誉，点击蓝字查看我的出书之路。

日常分享高质量文章，输出 Go 面试、工作经验、架构设计，加微信拉读者交流群，和大家交流！