6 ms·
All of the "when it's useful" examples are either of `any` or `comparable`. There are no examples restricted to an interface (other than `comparable` if that co
by orblivion 5y ago
All of the "when it's useful" examples are either of `any` or `comparable`. There are no examples restricted to an interface (other than `comparable` if that counts). Only the "when it's not useful" examples include a generic restricted to an interface, `[T io.Reader]`.
Since the language allows for restricting to an interface, and this is the language's official blog, surely there must be a recommended use case for it.
- Macha 5y agoI don't think the Go developers wanted to implement generics, but it was something they took a lot of heat for, and so while they relented and implemented the feature, they want to use their position to suggest "best practices" to limit their use.
- icholy 5y agoThe author of the blogpost has been making proposals for generics since Go 1.0 was released. Contrary to what some of the smooth-brains on here think, generics weren't implemented because of their incessant crying.
- pstuart 5y agojinx! you owe me a coke.
- zelphirkalt 5y agoUltimately a language lives through its users. If no one had complained about the lack of generics, the Go devs would probably not have liftet a finger to implement is, as per their original design.
- icholy 5y agoIt's like you didn't even read what I said...
- pstuart 5y agoMy understanding is that Ian Lance Taylor (the author of the post) was advocating for generics from the beginning. I'll take their official explanation of not sure how to do it cleanly and satisfy the original objective of fast compilation.
- jayd16 5y agoI don't know Go but I would say most uses of generics in other languages are "Any" style uses. The difference between a data structure that only takes any ONE type and a data structure that can only restrict to an interface is fairly huge. As the article describes, actual type safety is very nice. Edit: One trivial example might be a taking in a type and returning the exact same type. I don't think that's achievable with interfaces.
- eru 5y agoWell, Go's previous approach to generic sorting was pretty atrocious. Partially for the reason you suggested in your edit. To give another example: Go's type system couldn't even type an identity function before generics.
- orblivion 5y agoI think there may be confusion in language here. At no point am I asking about doing something that would reduce type safety. Supposing I have a function that takes [A any] and returns [A any]. As I use the function, it is not returning type "any" aka "interface{}", aka pointer to unspecified type (which has always been possible in Go). It's returning type A, which is specified at compile time, where A can be any type, but has to be the same type passed into the function. Supposing I have a function that takes [B io.Reader] and returns [B io.Reader]. Again, it doesn't return io.Reader, which again was always possible. Returning type io.Reader would be returning a pointer to unspecified type that implements the io.Reader interface. That sounds like what you thought I was saying. What I'm actually talking about is returning type B, specified at compile time, where B is restricted to types that implement io.Reader, and is also the same type passed into the function. In both cases, you're making a function that takes a type and returns the same type. In the second case, that type can only be one that implements the io.Reader interface.
- jayd16 5y agoExactly right. Now returning to your question... Is it not clear that you might want a method with this type safety that is also restricted to something more specific than [A any]?
- skybrian 5y agoNot necessarily. Sometimes features are allowed to make the language more uniform, not because they necessarily have a use case in mind.
- jrockway 5y agoSimple things like this will up being useful: func Clone[T proto.Message](in T) T { return proto.Clone(in).(T) } (proto.Clone(&somepb.MyMessage{...}) normally returns a proto.Message, but this returns a *somepb.MyMessage, which is nice.) I think we'll find reasonable uses all over the place. The place where I most want it is in the k8s client-go. All of the Reflector/Informer code I've written starts every event reception handler with a typecast of a v1.Object into the actual object you care about. With generics, that type checking can be done for you in advance. (I haven't thought about how all the codegen will be affected. Right now something like client.CoreV1().Secrets().List() returns a well-typed SecretList; return value dot Items's type is Secret, not Object. Obviously generics can do the same thing, the question is whether or not it's worth it when you already generate the necessary wrappers and "generic methods" anyway.)
- orblivion 5y agoI could find plenty of uses I like, I just don't know the ethos of Go well enough to anticipate what they'd consider "reasonable" vs "abuse".