go 泛型出炉，看起来还是不错的

[dbskcnc]

https://go.googlesource.com/proposal/+/4a54a00950b56dd0096482d0edae46969d7432a6/design/go2draft-contracts.md

Summary

While this document is long and detailed, the actual design reduces to a few major points.

Functions and types can have type parameters, which are defined using optional contracts.
Contracts describe the methods required and the builtin types permitted for a type argument.
Contracts describe the methods and operations permitted for a type parameter.
Type inference will often permit omitting type arguments when calling functions with type parameters.

This design is completely backward compatible, in that any valid Go 1 program will still be valid if this design is adopted (assuming contract is treated as a pseudo-keyword that is only meaningful at top level).

We believe that this design addresses people's needs for generic programming in Go, without making the language any more complex than necessary.

We can't truly know the impact on the language without years of experience with this design. That said, here are some speculations.

[reus]

@ruimz 我点进这个主题，本来也是想有技术上的讨论，谁知道看到一些菜鸡在那里拿些鸡毛蒜皮就说什么“这么菜”，“蛇精病”，实在忍受不了这些为黑而黑的人。

[liulaomo]

@reus

> “ go 是社区驱动的语言”，我认为是伪命题，语言设计，除了 go team 的人，有谁参与过？ go module 更是直接否定社区的 dep。try 也不是社区“驱动”，而是社区“阻止”，毫无建设性的反对。

这个不完全对。很多人都参与，但基本上都被 Go team 给否决了， ;D

[liulaomo]

其实不用<>可以理解，但是不用[]，就有点难以理解了。难道要和内置范型走两条路线？

[liulaomo]

@reus 其实说“ go 是社区驱动的语言”，并不为过。虽然语言本身基本上都是 Go team 设计的，但是 Go 能走到今天，离不开很多关键社区项目选择了 Go，也离不开众多 contributors 提出的众多 issues。其实 Go 在某些方面并不是和现在很多使用了 Go 开发的项目，Go 只是一个在当时相对比较好的选择。Go 能走到今天，得感谢这些项目的选择（相互感谢吧）。

[reus]

@liulaomo 绝大部分都是水平不够，社区从来没有人能提出像这个泛型提案这种篇幅的完整设计。但就算设计好了，甚至实现了，像 dep，问题解决得不好，也同样会被官方否决。社区能参与的，也就对官方设计提提建议，或者 vendor 这种改动小的。

[Hellert]

现在的错误处理可以接受，泛型有没有也无所谓，啥时候把内置十进制小数 decimal 类型提上日程啊，写财务类的程序没有这个真是麻烦死。

[reus]

@liulaomo 那是对“ go 生态”的驱动，我前面说的其实是对“ go 语言”本身的驱动。我挺讨厌拿“社区”来绑架官方对语言的设计的人，自己一时不适应，甚至根本未完全理解一个设计，就提出反对

[liulaomo]

@reus 有很多小的提案，至少我本人感觉不错，但基本都被 Go team 否决了。

btw，你觉得这个范型提案如何： https://www.v2ex.com/t/586881

[pisc]

@reus 你居然用 ML、Haskell 举例。。。要用<>还是()说实话根本不要紧，不过就是考量怎么不显式用∀来引入 type variable 而已。

> 泛型就是以类型作为参数，既然是参数，那放在括号里，有什么问题？ T(int) 就是以 int 为参数，特化出一个新的类型。

这是你的原话，我不是说 type level 之间是 currying 的，我说的是如果真像你说的，int 是很 trivial 的参数的话，为什么 type level 和 value level 之间是 currying 的，也就是 application 的时候是 T(int)(a, b)而不是 T(int, a, b)，为什么？不就是 type parameter 和 value parameter 在 golang 并不是那么 trivial 的关系么，所以为什么()不见得比[]或<>好的原因，因为是不同的 level，用相同的符号是很容易有歧义的。

你要是像其他语言 type variable 和 value variable 都可以当作普通变量调用和传递，那当然没问题了，你又举了 haskell 的例子，haskell 用个毛的<>，haskell 本身就是 separated annotation 而且可以直接写∀，当然不用考虑这些幺蛾子了。

[pisc]

@reus > 我是觉得“社区驱动”本来就是非常搞笑的事情，你社区驱动过什么了？

要是没有大把学习能力差、品味奇葩、张口闭口大道至简的 go 用户组成的社区，你 go 这破烂玩意儿能火？

[reus]

@pisc 因为类型参数不是函数签名的一部分，所以放不同的括号。可以理解成两次“调用”，一次做特化，一次调用特化后的函数。阅读时就可以这样类比理解，而不是一看到没用<>就说什么不好读。我举例是想说明，不是每一门有泛型的语言都用<>，别扭曲我的原意。

我十分希望 go 不要火，不要吸引培训机构，不要有脑残粉，不要惹上你这样的(消音)黑。

[tairan2006]

`<>`这个是不是会降低编译速度呀，虽然语法本身无所谓的

[duanquanyong]

@tairan2006 语法也有所谓的， `<>` 是有歧义的，可以单独出现，作为小于号或者大于号

[GM]

@xfriday
作为一个 Go 用户，对 Go 的一部分设计有意见还不允许我发表了？真有意思。
我发表这个观点收你钱了？这句话还给你。

[dbskcnc]

吵得是挺热闹的，但是似乎没 get 到重点
在 go 语言的设计原则下（简单不烧脑，便于工程实践，性能基本够用），增加泛型确实不是个轻松的事情，现有的其它语言解都有这样或者那样的弊端。

目前这个至少是衡量了各方面限制做出的一个可行解，放出来，经过各路神仙打磨，可用性还算是可以的，至少通用数据结构和算法库可以跟上当前编程语言界的水平

对于对此方案的各种意见，其实也只是我们各种 go 粉或者 go 黑的自 high 罢了，以 go team 浸淫计算机编程数几十年的功力，人家确实都懒得搭话，毕竟差距就是那么大，简单点就我们项目开发时一些新手的技术选型提议，多数只是天真的人云亦云罢了，真的很难有深刻的思考和实践

[darknoll]

@GM 爱用用，不用滚。

[neoblackcap]

@dbskcnc golang 作者原先就吐槽 C++的编译速度，因此他们坚持不能降低编译速度这个逻辑是自洽的。当然大家觉得好不好就另外一说。

不是说 go team 的经验足就代表他们比提案者厉害，有压倒性优势。大家都是受现代编译语言影响的人，提案者可不单单代表自己的知识储备，他还受这个业界最新的 PL 研究，多年来的 PL 实践影响。因此片面说其他人水平不够高是让人难以理解的。

其实不要说那么多，就是他们的追求跟大众的追求不协调而已。他们追求编译快速，自己觉得简单使用的语言，逻辑自洽。但是这说出来大家能接受吗？语言动了根本追求，哪怕是能做啊，那不就打了自己的脸？这才是根本问题。

[laumm1314]

范型怎么设计都不可避免其复杂性，go 引入范型是必须的么？

[judeng]

@jhdxr 为什么要用于 F<T>?
（对于有 C++/JAVA 经验的人）你看到的第一眼大概就能猜到这是什么东西。
（对于没有 C++/JAVA 经验的人）你看到的第一眼至少知道这是一个新玩意，并且绝对不会和 () 的那些语法混淆。
-----------------------
如果是仅这个原因，我觉得 parser 更简单点好

[dbskcnc]

@neoblackcap
1. 编译速度这个真的很有竞争力,使用 C++编译过大一点的系统,那感觉真的是解放(如果加上 go mod 的方便,那感觉就更不一样),当然也会有人指责说生成代码优化得不够好
2. go team 的人也不是原地踏步好不好,秒杀绝大部分人是没有问题的,当然三个臭皮匠顶个诸葛亮,go team 目前至少面上还是做了集思广益的工作
3. 这个很中肯,以目前 go 的水准,已经符合不少实际需要, 只是不少人也喜欢花衣裳