Go's updated generic proposal (Contracts)

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:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;proposal&#x2F;blob&#x2F;4a54a00950b56dd0096482d0edae46969d7432a6&#x2F;design&#x2F;go2draft-contracts.md#containers" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;proposal&#x2F;blob&#x2F;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&#x27;t find how to write a contract which requires a type must have some specified fields in this draft.

I&#x27;ve been doing some work in Dart&#x2F;Flutter recently and I&#x27;m finding it to be a nice mix of Java&#x2F;JavaScript&#x2F;TypeScript&#x2F;Golang. It has generics which work pretty well, although I&#x27;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:&#x2F;&#x2F;github.com&#x2F;dart-lang&#x2F;sdk&#x2F;issues&#x2F;37626" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dart-lang&#x2F;sdk&#x2F;issues&#x2F;37626</a>

I don&#x27;t understand what&#x27;s the difference between single-parameter contracts and interfaces. Aren&#x27;t contracts only useful when there&#x27;s two or more type parameters involved?<p>Edit: didn&#x27;t read through the whole thing, I guess contracts can do things that interfaces don&#x27;t. I think the overlap still makes things a bit awkward though.

Excellent example of clear and concise writing, introducing a subject.

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 &lt;&gt; 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 -&gt; {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&#x2F;ocaml

It is just me or do contracts look a lot like type classes.

There is some more information in this liveblog from Ian&#x27;s talk, Generics in Go [1], and the *.go2 files in Robert Griesemer&#x27;s change list [2]<p>[1]: <a href="https:&#x2F;&#x2F;about.sourcegraph.com&#x2F;go&#x2F;gophercon-2019-generics-in-go" rel="nofollow">https:&#x2F;&#x2F;about.sourcegraph.com&#x2F;go&#x2F;gophercon-2019-generics-in-...</a> [2]: <a href="https:&#x2F;&#x2F;go-review.googlesource.com&#x2F;c&#x2F;go&#x2F;+&#x2F;187317&#x2F;" rel="nofollow">https:&#x2F;&#x2F;go-review.googlesource.com&#x2F;c&#x2F;go&#x2F;+&#x2F;187317&#x2F;</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?

Honestly it just reminds me of Rust&#x27;s traits (granted I didn&#x27;t read the entite spec.), could this come with operator overloading too?

If what Generics fundamentally solve is having to type out an almost identical function for many types, why not just have macros?

For a second I thought it was related to {pre,post}-conditions.

I have knowledge in Python and never developed in Go, so I can&#x27;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) &quot;Discarded ideas&quot;, &quot;Comparison with Java&quot;, &quot;Comparison with C++&quot; before &quot;Design&quot; and after &quot;Background&quot;.<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, &quot;obvious&quot;, proposed solution.