Scrapping Contracts: a critique of the Go generics proposal

I think this proposal looks pretty good, but it does expose something odd about the core language. Given this example from the article:<p><pre><code> func Max(type T ordered) (a, b T) T { if a &lt; b { return b } return a } </code></pre> It would make me assume that if I were to write a function that looks like this, it would at least accept the same type of arguments:<p><pre><code> func AnotherFunction(a, b ordered) { ... } </code></pre> As in, substituting &#x27;T&#x27; with &#x27;ordered&#x27;. Unfortunately, it would not. In this case, the arguments are interface objects, which are pointers under the hood. Calls to the function have to be adjusted to pass in pointers. I think Go would have been more consistent if instances of interface objects always had to be prefixed by * . Concretely, this would throw a compiler error:<p><pre><code> func ReadStuff(r io.Reader) { ... } </code></pre> Instead, it should be written as follows:<p><pre><code> func ReadStuff(r *io.Reader) { ... } </code></pre> As in, r is a pointer to an object that implements the io.Reader interface.

This is, in my opinion, the best critique of the Go generics proposal so far. There&#x27;s more discussion on Reddit: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;golang&#x2F;comments&#x2F;9d1zsz&#x2F;scrapping_contracts&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;golang&#x2F;comments&#x2F;9d1zsz&#x2F;scrapping_co...</a>.

I also felt uneasiness with the definition of contracts but couldn&#x27;t put my finger on the reason. Merovious made now clear to me that the language to define contracts is the problem.<p>Nevertheless, I do think we need to keep contracts because they are a superset of interfaces. Interfaces specify only a collection of methods, and contracts specify a collection of methods and operations (e.g. ==). Remember that base types can also have methods. We may also want to restrict types to referenced, or unreferenced, because it determines if an assignment make a copy or not.<p>Contracts are types of generic parameters. I would find more natural to define these generic parameter types like this<p><pre><code> type foo generic { ... } </code></pre> As suggested by Merovius, the content would be a list of method signatures, operations, interface names or predefined operation set names.

To me, the most interesting part of this whole Go2 discussion is the amount of brainpower being expended on keeping the language on its current path of pragmatic minimalism and not careen off into type system land akin to contemporaries like Rust, C#, Scala and Swift, while at the same evolving and modernizing it. It&#x27;s not easy.<p>Not that complex and rich type systems are a bad thing, but there&#x27;s something to be said for Go&#x27;s austerity. Having been a Delphi&#x2F;ObjectPascal programmer for many years back in the 1990s, Go feels very familiar to me, with good approaches to many challenges. I do think Go&#x27;s designers made some crucial errors that should have been obvious at the time, and that we are paying for them now. In attempting its special flavour of minimalism, they arguably didn&#x27;t bother to learn enough from past language experiments. Of particular note, Modula-3 has a very pragmatic approach to generics [1], which later inspired similar approaches in Delphi&#x2F;ObjectPascal&#x2F;FreePascal. (I&#x27;m not saying Modula-3&#x27;s design is right for Go, though.) If you want to look at extreme engineering pragmatism (as opposed to type-theoretical elegance you find on Idris, Agfa etc.), look at Ada, or even plain Pascal. Both have range types and enums and other things which grant the language first-class mechanisms for tightening a program&#x27;s semantics, but they do so in the syntax and compiler, not through advanced type system shenanigans. (Oberon, which influenced Go in many ways, actually did away with enums in the name of simplification. Minimalism can go too far, too.) Ada, arguably the most engineering-oriented language ever conceived, also has tagged unions, although I don&#x27;t think they were ever used for error returns, since Ada has exceptions.<p>I&#x27;m not at all worried that Go adopting generics will lead to type system madness, especially given how conservative the designs have been so far. I think the amount of discussion and lively idea brainstorming in the community right now is a very healthy sign. More than some other language communities, there have been times when it&#x27;s seemed -- right or wrong, it&#x27;s hard not to get this impression from the vantage point of an ordinary developer -- that the Go team has historically been somewhat distant, preferring to unleash finished implementations on the world instead of evolving their designs in collaboration with the community (<i>cough</i> vgo vs. Dep), and I think this is an opportunity to open up the process a bit. I don&#x27;t know about anyone else, but I&#x27;m certainly very much enjoying all these articles being put out.<p>[1] <a href="https:&#x2F;&#x2F;www.cs.purdue.edu&#x2F;homes&#x2F;hosking&#x2F;m3&#x2F;reference&#x2F;generics.html" rel="nofollow">https:&#x2F;&#x2F;www.cs.purdue.edu&#x2F;homes&#x2F;hosking&#x2F;m3&#x2F;reference&#x2F;generic...</a>

I don&#x27;t mean this as a criticism, but it&#x27;s amusing how the Go community is slowly inventing Swift.<p>- &quot;Protocols&quot; that can be used as both constraints on generic parameters, and existential types<p>- Operator requirements in protocols<p>- Associated types<p>All of the above introduces a huge amount of complexity too, and I imagine trying to retrofit it onto an existing language that does not have generics is going to be an interesting challenge.

All these proposals are far too explicit and cause too much boilerplate code, someting that the Go team so far tried to avoid (or so it seems).<p>I‘d prefer a macro-like approach to generics where generic parameters are unconstrained like interface{} until they are used inside the function with constrained operators&#x2F;function calls, which define the limitations for the parameters. Just like a macro that expands to code that only works with particular types, it will simply generate an error when the compiler detects an incompatibility between the types used by the caller and the operations inside the function. This would be powerful enough and simple to understand.

I&#x27;ll admit that I don&#x27;t have much experience with generics, but can&#x27;t we get done what we&#x27;re trying to get done just by letting builtin operators get overloaded, then making an interface for those functions and using the interface? From what I&#x27;ve seen, it appears the main point is to let various types that can all get &quot;+&quot; applied to them get handled with one function. But defining the interface is the contract and the interface is any type that fulfills it, so...? What am I missing?