peter-mckenzie

Sum types instead of type lists

I like the direction the Go generics design draft has been heading in. There are however a few aspects that I feel could potentially be nicer so here's a design sketch/outline that attempts to address those. It maintains the spirit of the existing design, just frames it in a different way.

Overview

1. Any type may be used as a constraint for a type parameter. This is analogous to how any type may be used to constrain ordinary non-type function parameters. See (4) for details.
2. Type lists in interfaces are not part of this design.
3. Sum types are added to the language, along the lines of Roger Peppe's proposal.
4. There are three possibilities for type constraints:

peter-mckenzie

Here's an alternative Go generics syntax that uses the familiar <> but avoids parsing complexity by placing it to the left of the identifier. It's a bit (very?) unusual, but has the benefits of brevity and making the type parameters stand out.

Illustrated by converting some examples from Generics — Problem Overview :

type <T>List []T
func Keys(m map[K]V) []K