Go 2, here we come!

[Neia Neutuladh]

On Thu, 29 Nov 2018 22:20:50 +0000, JN wrote:
> https://go.googlesource.com/proposal/+/master/design/go2draft-generics-
overview.md
> here's some draft design, although I don't use Go so I can't say much
> about it

I feel like I can!

The proposal has a number of downsides:

* "contract" instead of "constraint" or "concept", which are the widely 
used terms. Go devs can't stand to use terminology the way normal people 
do.
* Functions and types can be templated, but member functions can't.
* Constraints are defined with an example function (basically just `if 
(__traits(compiles, ...))` as the only template constraint type).
* Constraints can't refer to symbols defined in their own package.
* Constraints define everything you can do with a type.
* There is no compile-time introspection.
* There is no function overloading. (Preexisting condition maintained.)

The last three combine to make it very difficult to write nontrivial 
generic code. You can write map/reduce/filter, and you can write some more 
complex stuff.

There are three main benefits here:
* You can write a function that takes arrays, channels, functions, and 
maps of a generic type. (These are builtin parameterized types, and 
interface duck typing doesn't extend to their parameters because of 
covariance / contravariance issues.)
* You can avoid heap allocations and indirect calls sometimes.
* You can be a little less direct referring to concrete types. This is 
useful if, for instance, you're trying to write an alternate 
implementation of an API that refers to concrete types you can't 
instantiate.

Overall, this is about as good as we could have expected in Go. It 
sidesteps the covariance / contravariance stuff in C# and Java, but no 
metaprogramming and the same recursive template limitations of D.