func Whatever[reader io.Reader](r reader) { ... }
There will be some other things that can be caught too, potentially.
It's… not, though?
In my understanding Go generics are reified, so this avoids boxing the reader, and should allow for static dispatch.
How useful that is can be debated, but that's hardly useless.
At the language level, it's a useless use of generics. Even if generics someday used a monomorphic implementation, the compiler would be able to translate those two things back and forth trivially.
>It's going to be a year or so before the community settles down again after this.
Rob Pike doesn't want to add generics to the standard library in this release (1.18) for the same reason[0]:
"<..>we have no experience with the use of the new types in Go on which to base a strong case for their design <..> For generics, we don't know what those new ways are yet. <..> I realize everyone wants to get their hands on the fun of the new language feature, and is looking forward to fixing some of the issues in the core libraries that will be less clumsy once it arrives, but I strongly believe it is best to take it slow for now."
I don't want to recommend "don't use generics", but generally think about whether or not you can solve the problem without them without immediately reaching for them. There are patterns in Go that work just fine today, which is why despite the fact that clearly some people are just flabberghasted at the idea that Go is useful without generics, it demonstrably is. Interfaces are quite a lot of what you need out of "generics". Don't just give up and copy and paste; it is necessary way less than some people who were trying to write C++ in Go claim it is.
As always in Go, follow the standard library. If they're hesitating to use generics, then that's solid advice.