It is not a proposal, it is a draft.<p>The new draft improves the contract part. But generic declaration part still looks some verbose. There are many repetitiveness, such as the Map example: <a href="https://github.com/golang/proposal/blob/4a54a00950b56dd0096482d0edae46969d7432a6/design/go2draft-contracts.md#containers" rel="nofollow">https://github.com/golang/proposal/blob/4a54a00950b56dd00964...</a><p><pre><code> func New(type K, V)(compare func(K, K) int) *Map(K, V)
func (m *Map(K, V)) Insert(key K, val V) bool
func (m *Map(K, V)) find(key K) **node(K, V)
func (m *Map(K, V)) Insert(key K, val V) bool
func (m *Map(K, V)) Find(key K) (V, bool)
func (m *Map(K, V)) InOrder() *Iterator(K, V)
</code></pre>
And I didn't find how to write a contract which requires a type must have some specified fields in this draft.
I've been doing some work in Dart/Flutter recently and I'm finding it to be a nice mix of Java/JavaScript/TypeScript/Golang. It has generics which work pretty well, although I've already found a very small bug in it [1].<p>Initial reading of this document makes me feel it is really over complicated compared with Dart.<p>[1] <a href="https://github.com/dart-lang/sdk/issues/37626" rel="nofollow">https://github.com/dart-lang/sdk/issues/37626</a>
I don't understand what's the difference between single-parameter contracts and interfaces. Aren't contracts only useful when there's two or more type parameters involved?<p>Edit: didn't read through the whole thing, I guess contracts can do things that interfaces don't. I think the overlap still makes things a bit awkward though.
I wish there was a way to have generics without:<p>* letting people being able to abuse them. C++ cough cough.<p>* making it clear to people reading the code what is happening.<p>I’ve noticed a few things:<p>* associated types in Rust are much clearer than generics<p>* one letter generics are “overly generic” and do not describe enough.<p>* the declaration of the type really adds verbosity<p>So what can a language do?<p>1. Maybe change the syntax to this one:<p><pre><code> func eat(food []generic.Type)
</code></pre>
Or<p><pre><code> func eat(food []g::type)
</code></pre>
Or something that doesn’t involve adding more <> or ()<p>2. Forbid one letter generic or force a description of the generic or even better: force listing all the types that are currently using this generic NEXT to the generic!<p><pre><code> g.type -> {egg, bacon}
func eat(food []g.type)
</code></pre>
But then you can’t use a generic from another package... but maybe it’s a good limitation?<p>Or force a generic to have a description, which is what golang is doing with interfaces. The problem is that we can’t combine difference interfaces like in Rust/ocaml
There is some more information in this liveblog from Ian's talk, Generics in Go [1], and the *.go2 files in Robert Griesemer's change list [2]<p>[1]: <a href="https://about.sourcegraph.com/go/gophercon-2019-generics-in-go" rel="nofollow">https://about.sourcegraph.com/go/gophercon-2019-generics-in-...</a>
[2]: <a href="https://go-review.googlesource.com/c/go/+/187317/" rel="nofollow">https://go-review.googlesource.com/c/go/+/187317/</a>
I don’t quite get what contracts are needed for?
This<p><pre><code> func Print(type T)(s []T)
</code></pre>
could be written as<p><pre><code> func Print(type T implements SomeInterface)(s []T)
</code></pre>
What am I missing?
I have knowledge in Python and never developed in Go, so I can't comment the Design choices. On the form, in my humble opinion, the PEP style is easier to read : presenting rational and constraints before the proposed solution.<p>It would mean moving (and a bit of rewording) "Discarded ideas", "Comparison with Java", "Comparison with C++" before "Design" and after "Background".<p>As a reader, I prefer to be presented with the problem first (with the constraints and previously explored ideas), then be presented the logical, "obvious", proposed solution.