3 ms·
> You're probably not still looking for an answer On the contrary! I think I got it, thanks. Not sure which version is simpler though, I've certainly never hi
by MrBuddyCasino 7y ago
> You're probably not still looking for an answer
On the contrary! I think I got it, thanks.
Not sure which version is simpler though, I've certainly never hit the "Mutually referencing type parameters" issue before. I guess using concrete types and avoiding vtable lookups is an advantage that matters to Go?
- hundt 7y ago> I've certainly never hit the "Mutually referencing type parameters" issue before. I don't think I have either, but according to that document supporting this use case was considered a minimum requirement for generics. I don't know that much about generics but maybe it comes up more often than we realize. > I guess using concrete types and avoiding vtable lookups is an advantage that matters to Go? It avoids the vtable lookups and also, in cases like the mutually referencing type parameters, provides compile-type type-checking, which you don't get with the interface-only solution. I'm also not sure how your proposed solution extends to parameterized types. Certainly a central motivation of generics is make something like LinkedList<T> possible.