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.

[gamexg]

这个大概什么时间能够用上？

[trait]

Why not use the syntax F<T> like C++ and Java?
When parsing code within a function, such as v := F<T>, at the point of seeing the < it's ambiguous whether we are seeing a type instantiation or an expression using the < operator. Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser simple.

啧啧，go 语言组这么菜的吗，上次 try QA 也拿 parse 当说事，你们什么时候能认识到对用户 simple 和你实现 simple 不是一回事？

[ipwx]

@trait 所以 Go 语言设计者一直都很蛇精病

[useben]

大概看了下，没有历史包袱就是好。引入了类似接口定义的约定和关键字 contract，看起来还不错

[sillyousu]

@trait

帮你高亮
Resolving that requires effectively unbounded lookahead.

[GM]

@sillyousu 所以就理所当然地把复杂性丢给了用户？

[xfriday]

大概看了下，contract 似乎可以取代 interface 了，功能更强

[xfriday]

@GM “ In general we strive to keep the Go parser simple.” 人家 go team 收你钱了？开发组有自己理念，你没有权利绑架，你不是上帝

[lynskylate]

@xfriday 开发者不是社区的一部分？ go 不是社区驱动的？

[sillyousu]

@GM

这里面有很多考虑因素吧：编译速度、Go parser 复杂度、周边工具复杂度（ lint、代码补全）、是否兼容现有的语法。

比起熟悉的语法，我选择上面这些。

[lynskylate]

@ipwx keep thr Go parser simple 这个实在是太不能理解了，一个编译器的前端和用户有什么关系，c++parser 留下了羡慕的眼泪

[ptyfork]

@GM
用 F<T> 就简单了？ 那不过是用多了 java 先入为主而已。
引进范型就一定引入复杂度，对使用者和语言开发者都是负担，跟所用的语法关系反而关系不是很大
反而就目前 Go 中的设计，没有历史包袱，简单看了一下，跟 Go 语言之前的语法一致性保持的很好，对新手来说更友好。

[reus]

@trait 你可以了解一下为什么 C++会引入 typename 这个东西，你真以为<>是“对用户 simple ”？

[reus]

@xfriday 并不能，interface 是一个类型，例如 []io.Reader，在运行期，元素可以是任意实现了 io.Reader 的类型。但假如是 []T，那元素只能是特化了的那个类型。interface 是用于运行期动态分发的。

[reus]

@lynskylate go team 不是开发者一部分？整个编译器都是 go 写的，好不好用，他们自己不会判断啊？就你聪明。

[reus]

@sillyousu 他可能没写过 parser 吧，根本不知道 unbounded lookahead 代表什么。


@trait 敢说提案作者菜，看来你比 Ian Lance Taylor 还牛逼？

[reus]

@GM 难道把 () 改成 <>，就降低了复杂性？泛型就是以类型作为参数，既然是参数，那放在括号里，有什么问题？ T(int) 就是以 int 为参数，特化出一个新的类型。

[linghutf]

什么时候能上？

[nguoidiqua]

很多人真是先入为主，老实说当初 Java 的泛型我是很迷糊的，当然搞熟了就会觉得很简单很自然了。

但如果你因为这样就觉得非此不可，那么就是自己封闭了自己认识新事物的能力，过去的习惯不知不觉就成了你思想的枷锁。

[trait]

@sillyousu 现在的 parser 技术实现 lookahead 不要太简单，这并不会让 go parser 更 simple