Passing in two type parameters, one which is the type used by the caller and one which implements the interface, would almost work if conversions were allowed between type parameters with the same underlying types:
https://go2goplay.golang.org/p/ylchcyACuV7 You have to double parameterize everywhere explicitly, though. I'm not quite clear what the advantage would be compared to passing in the comparator, other than the tradeoffs for static vs. dynamic. Another option for abstracting over builtin and custom type cases would be to add namespaced extension methods. Basically, a package could add methods to a builtin type which are namespaced by the package, and then interfaces could qualify their method names with the particular package whose methods they want to use. Downstream packages would be able to satisfy these methods only for the types they define, like with normal "free" methods. This change would potentially have a far reaching impact, but it would sidestep needing to add a lot of names to the language. type CustomOrdered(type T) interface { package.Less(other T) bool } func (x int) package.Less(y int) bool { return x < y } It would be nice if you could do this for all types that implement constraints.Ordered in one definition, but that's a whole other can of worms. One way to address this would be if you could On Thu, Jul 2, 2020 at 7:59 PM, ben...@gmail.com <benh...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/7f471eba-be08-4d32-a50a-22939f63b76dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CANjmGJs8F3m1DrGh6mzGngvCP%3DYBr4EPbiKfc8XAoRgK%2BrZY6A%40mail.gmail.com.
