共计 1536 个字符，预计需要花费 4 分钟才能阅读完成。
大家好，我是煎鱼。
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/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。
参考
- proposal: constraints: move to x/exp for Go 1.18
- proposal: constraints: rename package to “of”
