大家好，我是煎鱼。
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 这个命名咋样，欢迎大家一起来讨论：）
若有任何疑问欢迎评论区反馈和交流，最好的关系是互相成就，各位的点赞就是煎鱼创作的最大动力，感谢支持。
文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blo… 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。