This proposal would not allow any generic functions (except for methods on generic struct types), or generic non-struct types. That goes against the principle of orthogonality which Go seeks to follow. There's probably more problems, but this is a big one.

Interesting observation, I have always thought about orthogonality as being mostly a function of preventing there from being two different ways of accomplishing the same task, rather than making sure that as many permutations of features are usable together as possible. I am curious how important you think it is to have compiletime parameterization based on anything other than types, like integers, first-class functions, or other go types. I considered for a while a simpler version that just allowed type fields, rather than arbitrary const fields, but the idea of a sort function with a custom compare function that could be inlined at compile time (const func) was really attractive, not to mention binary size improvements from const config structs or other such cases.

One primary goal I was trying to accomplish was to follow the principle of least surprise, ideally to the point of making functionality that someone learning the language today would expect to work already, and be surprised does not exist. Contracts don't feel to me like they rise to that level of intuitiveness, but "fields of structs can be type constants" does. I'm curious what your thoughts are.

I think the lack of support for generic standalone functions is not that big of a deal in real large-scale programs, although it looks significant on tiny examples. Especially with the pattern of size-0 structs acting as user-declared "packages" of functions, I'm OK with there being a little more typing required to be explicit about using generic functions, and sort.Sorter{int}.Sort(l) isn't actually that much longer than sort.Sort<int>(l).

Interesting proposal. Why not also allow const type also in parameters to functions, to get generic functions also? And for the contraints of cont type, interfaces should also be allowed in the constraints block after them.

@beoran The original intent behind not allowing const arguments to functions was to separate the place where you feed the types into a generic function from the place where you call it. This makes tooling (including compiler messages) simpler, because any function will always have a specific concrete type at the time it is called, and figuring out a valid set of arguments for it doesn't risk becoming a complicated task. It is definitely a little bit verbose, but it felt to me like a little more keyboard-typing would be better than a little more complexity in this case. I'm curious to hear your thoughts, particularly around the pseudo-package pattern used in the sort example. If you have an example where a generic function (not a method) is actually needed, that could be interesting as well.

Regarding constraint blocks, interfaces would definately be allowed and encouraged in those blocks, both for simple cases and more complicated things like the graphutils example, where the interface constraint actually changes based on previous const types.

I have seen many Go Generics proposals, and while this has some good ideas, I think it ends up being less powerful than it could be. I implemented something similar to this proposal, using text/template to generate Go files. Having types as parameters to functions for generic functions, like in may other generics proposals seems to be a more promising and powerful approach.

@beoran
Those are good points, although I am skeptical a template-based system can guarantee that errors are always detectable by the library author.

I think we should be careful to not just make generics maximally powerful, in a similar way to the fact that interfaces in Go "only" support methods, not fields or any other properties of types. It requires some more work from the programmer on occasion (like making getters), and is arguably less powerful than an interface syntax that also allowed direct specification of fields, but is also simpler, which is important. I worry that many/all of the more powerful generics systems I have seen proposed are also, by their very nature, hard to reason about what types can be used where (or turing-complete in the worst case). Much like how Go modules are intentionally limited compared to something like dep, I think we need a slightly more limiting generic system at the benefit of significantly simpler behavior.

If you are aware of other proposals that fall into that bucket (or that otherwise disallow confusing and complicated type signatures), I would love to hear about them!

For the sake of having all the discussion in one place, I'm copying here a conversation with @ianlancetaylor from the golang-dev mailing list.

Thanks.
I don't understand how to write an Index function, which takes a slice of some element type and a value of that element type. In the design draft:

func Index(type T)(s []T, v T) int

How do I write a function that takes two values of related but not identical types? Are you also suggesting that we extend parameter types to permit them to be elements of previously specified
parameters?

Ian

This proposal intentionally does not support generic functions that are not methods, so the answer is to make a type of a 0-size "Indexer" type that is parameterized off of the element type, and has an Index method that does what you want. This adds a little bit of code overhead, but makes it more explicit when you are instantiating a bunch of generic functions. In practice, you would probably make a WrappedSlice type that has helpers for several things, not just Index, decreasing the overhead (like example 3 in the doc).

type Indexer struct{
   T const type{types.Equality}
}

func (i Indexer) Index(s []i.T, v i.T)int{}

Used as either...

intIndexer := utils.Indexer{int}
//...
intIndexer.Index(...)

// -- or --
utils.Indexer{int}.Index(...)

Effectively, force the user of the method to explicitly specify the leaf types ("int"), then build the type signature of the method from those.
In this proposal, parameter or return types can specifically only be elements of the method receiver, which I think is a simpler mental model than generally allowing them to be methods of any previous parameter.

I have also updated the document with a brief bullet point about this issue, since it has come up multiple times.

Let's see how the current generics design draft, which does permit generic functions, plays out. If that does not get adopted, we can return to this idea.