Go generics are going to be both simple and complex (as of Go 1.18)

January 25, 2022

It's all but certain that generics will be in Go 1.18 when it's released not too far from now. I don't have strong feelings about Go having generics, or about the design that people settled on; the current design strikes me as boring, which I feel is a good thing (and which has been the case since the iteration of the 'contracts' design). But boring doesn't mean straightforward, as we've seen in other aspects of Go's design, such as addressability.

So far, basic use of Go's generics seems pretty straightforward and simple. The syntax is reasonably obvious and memorable for simple examples, and the standard constraints package will take both the drudgery and some of the errors out of writing generics that accept only restricted sorts of types, like 'all integers' or 'all numbers'. I can even imagine using basic generics in my own code, although I'm not sure that that's a smart idea. The current Gotip playground is a nice place to play around with this simple usage.

(A few times I've found myself implementing basic operations repeatedly for full maps and 'maps as sets' that only vary slightly in their types, and maybe a bit in their usage. Generic-izing what is almost cut and paste code is at least superficially tempting, although it may actually be a sign of deeper issues in my code.)

At the same time, the current way of doing generics (also) is not simple. For example, I've tried to read and follow various iterations of the generics design, and there are things the current one says that I certainly don't understand. Some of the implications of requirements and constraints in the design are clearly tricky, in the same way that the corners of addressability are. For another illustration of this, Jaana Dogan's Generics facilitators in Go discusses something obvious you can't do in this version of Go generics and how to get around it. The official generics proposal does discuss this issue, but it gets condensed to a small paragraph:

Although methods of a generic type may use the type's parameters, methods may not themselves have additional type parameters. Where it would be useful to add type arguments to a method, people will have to write a suitably parameterized top-level function.

I expect there to be things that take people a while to really learn and understand in practice, for example this example of type inference. The whole issues section points out various minefields in the process of talking about things the current proposal doesn't deal with.

Using powerful generics is also somewhat complex, as we can see in one of the proposal's examples. Figuring out that sort of deep, interlinked generics design is a skill that's going to take people time to learn.

(This sort of elaborates on a tweet of mine looking forward to people's explainers of generics when 1.18 is released.)

PS: One area of quiet complexity is what it means in practice to put various types of things into an interface type used as a type constraint. I don't think the proposal talks much about this specifically, but see eg Embedded type parameter methods and Composite types in constraints.

Written on 25 January 2022.
« DNS queries to external sources do fail every so often out of the blue
Giving things an IP address is dangerous (to them) »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jan 25 00:31:46 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.