Generics catch-all

[abhinav]

Go 1.18 will include support for generics. It will take some time to use them regularly before we can establish best practices and idioms.

This discussion is intended to be a catch-all for us to track ideas and conversations on the topic. We can discuss patterns we encounter, pros/cons, etc. here, and use them to establish guidance for the style guide.

[abhinav]

Libraries that follow the Go Support Policy (most of ours) of supporting the current and previous minor versions of Go will have a problem come 1.18: code that uses generics will not compile in 1.17.

For libraries that want to use generics before Go 1.19 is released, we think that any use of generics should be build-tagged with //go:build go1.18, and if relevant, alternative code paths should be available for Go 1.17.

[abhinav]

@sywhang pointed out, one antipattern we've seen with generics:

func foo[T someInterface](p T) {
  // ...
  p.Method()
}

This doesn't actually make any use of the generics functionality and can be written as,

func foo(p someInterface) {
  // ...
  p.Method()
}

(If the function needs to return T, that actually does make effective use of the functionality.)

Not yet a recommendation in the guide because we need to figure out a more formal guidance around it.

[sywhang]

From @mway :

Constraints must be exported if the type they're parameterizing is also exported.

Example: https://github.com/uber-go/zap/blob/4b03bc56483d64b4714462e513099701e62b43d3/array_go118.go#L104