为什么没有Go的泛型？ [英] Why no generics in Go?

问题描述

免责声明：我现在只玩了一天Go，所以很有可能我错失了很多。

有人知道为什么会有没有真正的支持泛型/模板/ WhatsInAName在Go？所以有一个通用的 map ，但这是由编译器提供的，而Go程序员不能编写自己的实现。所有关于使Go尽可能正交的讨论，为什么我可以使用泛型类型但不创建新类型？

特别是当涉及函数式编程时，那里是lambdas，甚至是闭包，但是对于缺乏泛型的静态类型系统，我该如何编写泛型高阶函数，如 filter（predicate，list）？ OK，链接列表等可以通过 interface {} 牺牲类型安全来完成。

在SO / Google上没有透露任何见解，它看起来像泛型一样，如果有的话，将作为事后补充加入Go。我确信汤普森比爪哇人做得更好，但为什么要把泛型放在外面？或者他们是否计划并且尚未实施？ 解决方案

这个答案你会在这里找到： http://golang.org/doc/faq#generics

为什么Go没有泛型？

泛型可能会在某些时候添加。尽管我们理解一些程序员的做法，但我们并不觉得紧迫。

泛型很方便，但是在类型系统和运行时复杂性方面，时间。我们还没有找到一种能够使复杂性与价值成比例的设计，尽管我们继续考虑这一点。与此同时，Go的内置地图和切片，以及使用空接口构建容器（使用显式拆箱）的功能意味着在许多情况下，编写代码可以实现泛型将启用的功能，如果不那么流畅。

这仍然是一个未解决的问题。

Disclaimer: I've only played with Go for one day now, so there's a good chance I've missed a lot.

Does anybody know why there is no real support for generics/templates/whatsInAName in Go? So there is a generic map, but that's supplied by the compiler, while a Go programmer can't write her own implementation. With all the talk about making Go as orthogonal as possible, why can I USE a generic type but not CREATE a new one?

Especially when it comes to functional programming, there are lambdas, even closures, but with a static type system lacking generics, how do I write, well, generic higher order functions like filter(predicate, list)? OK, Linked lists and the like can be done with interface{} sacrificing type safety.

As a quick search on SO / Google did not reveal any insights, it looks like generics, if at all, will be added to Go as an afterthought. I do trust Thompson to do way better than the Java guys, but why keep generics out? Or are they planned and just not implemented yet?

解决方案

this answer you will find here: http://golang.org/doc/faq#generics

Why does Go not have generic types?

Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.

Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.

This remains an open issue.

这篇关于为什么没有Go的泛型？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！