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.

[trait]

某些 gopher 是没有任何思考能力的，当初有人抱怨为什么 err 这么简陋，为什么静态语言不给范型，这些人像传教士一样在各大论坛强行定义 simple，认为这些东西会让 go 过于复杂，如今 go 开始加这些“繁琐”特性，又开始各角度自洽
ugly =/= simple，连 parser 这种都有一套完整的自动化流水线模块都交给用户肉眼 parse，真的 simple

[pisc]

@reus > 泛型就是以类型作为参数，既然是参数，那放在括号里，有什么问题？

为什么 type parameters 可以 currying，而其他参数不能呢？

[mywaiting]

看完楼上的回答，我决定继续写 python

[Sasasu]

啥时候有编译到 go 的语言

[jhdxr]

@reus 是是是，整个 v2 就你写过 parser。别的语言的实现也都全是傻逼 X。golang 最厉害了，吼不吼啊？





为什么要用于 F<T>?
（对于有 C++/JAVA 经验的人）你看到的第一眼大概就能猜到这是什么东西。
（对于没有 C++/JAVA 经验的人）你看到的第一眼至少知道这是一个新玩意，并且绝对不会和 () 的那些语法混淆。

go 吹：没关系我自己累点眼花没事，parser 千万不能受累

[artandlol]

golang 相对于其他语言，赶紧更加严谨，所以会导致整体落后。跟苹果在很多功能方面落后安卓一个道理

[rockyou12]

写 python 要游标卡尺，写 go 以后要啥？啥东西数括号比较方便？

[stephen9357]

@reus 别杠了，Go team 是开发者的一部分，那 Golang 的使用者就不是了么？你这逻辑硬伤很严重。人家看不惯这种做法，表示反对怎么就不行了，非得 Golang 怎么做都叫好你才满意么，赶紧相互 block 吧，别瞎哔哔了，看着都尴尬。

[wo642436249]

看一堆人在这里争来争去，估计没有一个是在大厂工作😂

[reus]

@pisc go 这个提案的泛型参数并不能 currying，如果泛型需要 A, B, C 三个类型，那特化时就必须一起传入，并不能 currying。所以你的说法不成立。

[scnace]

contract 和 try 的概念大概 18 年就被 Go Team 提出来了吧 ，现在 try 被社区否决了，contract 还能活多久🙈

[reus]

@jhdxr parser 当然不能受累，编译快本来就是 go 的目标之一。别的语言不在乎编译速度，只是取舍不同，我可没有说过取舍不同就是傻叉，是你自己脑补的，别泼脏水啊。我可不是因为想吹 go 才这样说，纯粹是觉得有人傻逼，忍不住要吐槽啊。

所有 ML 系语言都是用 ()，scala 用 []，D 用 ()，Haskell 也没有 <>，为啥非得为了照顾一些连基本的学习能力都没有的人，而选择一种会带来歧义和降低编译速度的语法？

当然，如果 go team 能发现一种算法，让 <> 不需要 unbounded lookahead，我也能接受。本来就是个鸡毛蒜皮的事情，就只有菜鸡才纠结语法问题。go 连类型位置都和 C++ / java 不一样了，适应不了的人，何苦要用。

[reus]

@stephen9357 “看不惯”不是什么理性的理由，不是什么技术上的理由，纯粹是一个人学习能力低下，适应能力低下的表现。不用 <> 是有技术上的理由的，你不能用非理性非技术的理由，去反驳一个技术性的理由。

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

[hhjj3388]

@jhdxr 没错··搞个() 让人混淆, 那个什么接收者也是 () 加参数() 加返回值()```````````````

[ruimz]

@reus 这个问题同样给你，你社区驱动过什么了？你没社区驱动过就觉得搞笑？
讨论就讨论，不要付诸人身攻击。

[congeec]

@trait #21 对啊。 规范和实现绑在一块儿的语言用起来就是别扭。python 是这样，js 是这样，还好 rust 已经开始移除 turbofish
::<>了

[reus]

@trait lookahead 从来都不是问题，问题在于时间复杂度，现在 go 语法用 lalr(1) 就能解析，O(n)就能解析，引入带歧义的语法，可能连 parser generator 都不能用了，像 C++ 一样。甚至需要引入 typename 这种纯粹是为了消除歧义的东西。

go 粉自然有傻逼，尤其是那些做培训的，本身水平就低，又整天喊“学不动”，尬吹什么大道至简。
go 黑的傻逼，不比这些 go 粉少，一看到和自己学过的东西有一点点不同，张嘴就是 ugly，为黑而黑。你跟他说技术原因，根本理解不了，根本就懒得去理解，整天想的就是怎么“黑”。

[lynskylate]

@congeec ？？ python 规范和实现并不是绑在一起的啊，pypy jython ironpython，python 的各种实现有哪种语言比他多？唯一诟病的只有 c 拓展，python 暴露了太多内部细节导致 c 拓展不能在各种实现中迁移罢了

[reus]

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

[reus]

@congeec go 有 google go, gcc go, llvm go, tiny go, gopherjs 等等实现，规范和实现不绑定