Hi folks, This thread <https://lobste.rs/s/ac83w9/generics_for_go#c_rhztuq> on lobste.rs made me wonder if the difference between type-list constraints and method-interface constraints is going to cause a bunch of issues or code duplication. There's a lack of orthogonality here that makes me uneasy.
For example, the Smallest() function in this proposal takes a slice of []T, where T is "type T constraints.Ordered", a type-list based constraint. That means Smallest() will only work with the built-in types specified in the type list (or types with one of those as an underlying type), and can't be used with more complex struct types. For it to work for other types, you'd have to write a second version of Smallest() -- code duplication -- that took a method-interface based constraint like so: type CustomOrdered(type T) interface { Less(other T) bool } Arguably Smallest() would still be quite useful even if it only works for builtin integer and float point types, but with the type-list Ordered it wouldn't work for (say) big.Int, a custom Decimal type, or a more complex struct type. But I think this is worse for ordering-based *data structures* like Tree of T. If done with the type-list Ordered, the tree could only store built-in types, which isn't that useful. Using a constraint like CustomOrdered would work and be more flexible ... but then a basic Tree(int) wouldn't work. You'd have to do Tree(MyInt) and convert everything from int to MyInt on the way in, and MyInt back to int on the way out -- a bunch of type conversion boilerplate. Or you'd end up writing two versions of your generic Tree: BuiltinTree that uses Ordered (type lists), and CustomTree that uses CustomOrdered (interface with Less). Not very nice. (Here's some Go2Go code which shows this for Smallest: https://go2goplay.golang.org/p/Rbs374BqPWw) I'm not sure how the proposal solves this for something like Smallest() ... I don't think it does. For ordered data structures, like the Map example, it passes in a custom "compare" function to the initializer and kind of side-steps the issue. Which isn't bad for data structures as it'd still eliminate a lot of code, but it would be kind of a pain for little algorithms like Smallest(). Thoughts? -Ben -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7f471eba-be08-4d32-a50a-22939f63b76dn%40googlegroups.com.