大家好，我是建宇。Go泛型被各种标准库支持，例如常见的映射和切片泛型库。在早期他们看起来像这样：,Vany](mM)[]V...或者：packageslicesfuncCompare[Econstraints.Ordered](s1,s2[]E)int...注意里面的标准库constraints，今天改了主角。他究竟怎么了？背景标准库约束是一个新奇事物，由泛型大师IanLanceTaylor于2021年9月24日提交《constraints: new package to define standard type parameter constraints》添加。如下图所示：主要功能是添加一个约束（constraints）包来定义一些标准的、有用的约束，所以我们会在通用库中看到这些标准约束的使用。提出新提案的原因是在社区中引起了激烈的讨论。有人提出了一个提案《proposal: constraints: rename package to "of"》，希望重命名约束包。新代码如下：funcAbs[Vof.Number](vV)V{...}funcSum[Kcomparable,Vof.Number](mmap[K]V)V{...}作者认为使用“of”关键字比“constraints”更简单、更流畅。这个提议引起了很多讨论。我觉得现在的名称约束太长了。一旦函数签名多了，就会很繁琐，看着不舒服。建议使用引用别名来解决：“constraints”的导入也有说是使用any，isname，甚至std，或者其他导入方式。众说纷纭。虽然后面constraints的使用频率有了很大的优化，但是一旦用到2、3次，就会出现函数签名过大的问题。最终因未能达成明确共识而被否决。苦苦挣扎的结论经过长时间的通用改进和命名争议后，RussCox发现约束包仍然存在许多问题并且有待商榷。分别是：包名太难看：很多人对包名很满意，就是约束，也有人很不满意，认为太长太罗嗦。不知道该放什么：对于要放入一个包中的东西，不清楚哪些接口是重要的并且应该存在，哪些不应该存在。似乎不需要：起初人们认为标准约束是使用泛型的基础，但在实践中并没有证明是这样，甚至可能是不必要的。基于以上原因，Go团队决定将标准库约束，如maps和slices转移到x/exp中，并将其作为实验函数。然后在Go1.19或1.20中重新审视它们，看看它们是否真的有用，或者如何使用它们才是正确的方法，然后再做决定。总结Go泛型将在本月（2月）Go1.18发布（春节期间通知社区三月...），虽然表面上看核心功能已经基本敲定，但是支持的设施还是比较乱。建议大家在正式制作使用中注意节奏，以免踩坑。您如何看待名称限制？欢迎大家一起讨论：）如有任何问题，欢迎在评论区反馈交流。最好的关系是相互成就。您的好评是创作炸鱼最大的动力。感谢您的支持。文章持续更新中。可以微信搜索【脑补炸鱼】阅读。本文已收录在GitHubgithub.com/eddycjy/blog中。学习Go语言可以看Go学习地图和路线。欢迎星星提醒。参考proposal:constraints:movetox/expforGo1.18proposal:constraints:renamepackageto"of"
