一个感觉可读性比官方范型草案要高的提案

用 function body 做泛型约束，就已经谈不上“可读性”了，新的 contract 提案和旧的比较，最大的不同就是泛型约束的语法不再用 function body。

@reus
这个提案也可以不用 function body 来做约束的。

这下面有很多例子中使用了不带 function body 的 contracts。
https://github.com/dotaheor/unify-Go-builtin-and-custom-generics/tree/master/examples/src/go

个人感觉此提案相对官方草案有以下优点：
1. 和内置范型更接近。
2. 主题语法完全和 Go 1 兼容.
3. 相对于官方草案，少了很多新语法。

感觉类似 D 的模板
https://en.wikipedia.org/wiki/Generic_programming#Templates_in_D
https://en.wikibooks.org/wiki/A_Beginner%27s_Guide_to_D/Templates_and_Generic_Programming/Template_Classes
https://dlang.org/spec/template.html

@reus 事实上，此提案更多地借鉴了 C++模板。C++模板不滥用的时候，其实可读性还是挺高的。

@reus 是很像模板
@liulaomo 对于大型程序，可读性和对实现代码的依赖是较大的问题
C++搞 concepts 了，Go contract 草案也许可能参考了这个，参见 B.S.老爷子的文章 Concepts: the Future of Generic Programming

@reus 和 D 模板还真有店像。
https://en.wikibooks.org/wiki/A_Beginner%27s_Guide_to_D/Templates_and_Generic_Programming/Mixins

应该说兼有 C++（但 type/function 输出）和 D （多个输出）模板的特点。


@sorra 这老爷子准备把 C++设计成百科全书吗？作为一个只懂 C++98 的大叔，表示看不懂新世纪的 C++代码。

go 不加泛型也挺好的，写出了 docker 和那么多云原生的组件。港真，go 语言没有必要加泛型，避免增加语言复杂度

@liulaomo c++没有 concept 做约束的话，可能展开很多层才抛错，错误信息就很难理解了。contract 是和 concept 很像的

@Cbdy 加了范型不想用可以不用啊。但对于某些项目来说，范型很重要。目前 Go 主流项目扎堆于于网络和工具一个重要的原因就是缺少范型。范型可以帮助 Go 开拓新的疆土。