Comment by arendtio

Some people here seem to not like the similarity to interfaces, but I think, it should be even more like interfaces. In fact, I like the interface syntax even better than the contract syntax. And the type parameter list pollutes the otherwise very clean syntax in my opinion.

So you might ask what I am suggesting. AFAIK there are two major problems preventing interfaces to be used as generics:

1. There is no way to require the methods of builtin types aka operators.

2. Compile-time type safety is very limited

The reason why interfaces have no access to operators and other language features is that the language is kinda rough around the edges. And I really don't want to hurt anybody with this statement. I love the language, but I think there are some things that aren't perfect.

For example, just imagine every array/slice would have a method (e.g. Position(int)) that would be the equivalent of the square brackets and the square brackets would be just some syntactic sugar like

  arrayA[0] == arrayA.Position(0)

Same thing for operators like +

  x := 1
  x + 2 == x.Addition(2)

It would eliminate a lot of cases that make contracts necessary. In essence, it would mean that you could actually address built-in types in interfaces.

The second problem is related to the type parameter list. In my opinion, it would be better to simply put those types on extra lines like:

  type T Generic
  func Print(s []T) {
    // function body
  }

I mean, there should be no problem in making them available for more than one function and it would definitely clean up the function signature and look more Go-like.