Go team proposes parametric polymorphism

Go team proposes parametric polymorphism

The team behind the Go programming language released an updated draft for parametric polymorphism (pp).

Inclusion of Generics, which to the Go team is another way of phrasing pp, was one of the most requested changes in the 2017 Go survey, and was therefore a major focus in 2018. The feature is also on the list of improvements the team is looking to ship with Go 2

This doesn’t mean too much however, as a proposal to add a try function for error handling recently got canned due to the amount of critical feedback the team received. Error handling – though apparently on lots of people’s minds – is “on the backburner” for now, since quite a lot of resources went into the last proposal.

The generics design document is similar to one that was presented last August, but with a reworked syntax, which should address some of the issues language users had with the old draft. Devs familiar with the Ada language will find themselves reminded of the approach to parametric polymorphism that can be found there (syntax aside).  

The contracts-dubbed draft intends to add optional type parameters to types and functions, which allow programmers to write “generic” code that can be specified later. Template metaprogramming or other forms of compile time programming have been omitted for the proposal.

The draft includes so-called contracts that define which operations on values are permitted for a type. Contracts can be “considered as a set of constraints, where the constraints are either methods or types”. Devs are meant to use them to validate a set of type arguments or describe “what the function using the contract, [..] is permitted to do with those type parameters”. 

Contracts may only appear on the top level of a package and can embed other contracts. They receive type parameters in the order in which they appear, and methods within a contract “may refer to any of the contract’s type parameters”. More details about how this all is supposed to look like, and how it is different from other generics, can be found in the design document.

To keep errors to a minimum and make sure the generic programming implementation scales, the Go team has given out the rule that, whatever the final definition looks like, “there should be an explicit contract between the generic code and calling code”. Another restriction of the draft is, that methods “may not themselves have additional type parameters”.

Like this, details of when exactly a method with type arguments implements an interface don’t have to be specified at this point. If type arguments could be of use to a method, devs will have to come up with a parameterised top-level function.

There isn’t any discussion about the inclusion of Generics in any of the upcoming 1.x releases yet. Issues with the draft can however be raised over at GitHub already. The team also wants to address some of the design aspects that need more detailed discussion early on. A list of those can be found in the repo as well.