On Mon, Jun 22, 2020 at 2:53 PM Ian Lance Taylor <i...@golang.org> wrote: > > On Mon, Jun 22, 2020 at 1:41 PM Ankur Agarwal <akah...@gmail.com> wrote: > > > > I like the idea of generics, and having played around with them it > > definitely feels worth bringing into Golang. But, I agree with the author > > of this post and I don't think constraints on generics is needed. > > > > I do understand the arguments that: > > 1. There's no implicit conversion between a value type and an interface, > > and constraints would make this possible, but i feel that it's at the > > expense of making the language unnecessarily complicated. Can we not just > > think through our design of our applications to either prevent this need or > > ensure that we build a slice of interfaces? > > 2. Being able to constrain on comparable values (using <,>,==,!=). Couldn't > > we create an interface which declares what we need (LessThan, MoreThan, > > etc)? I feel that if the language goes down this path, why not do the whole > > shebang and have operator overloading in go?
It does not make much sense to constrain a type to have less-then, greater-than support in a language without operator overloading. There is a finite list of types that support LessThan, so it is more explicit and simpler to list the types you expect in a generic function (think "i expect to receive a string or int" as opposed to "i expect to receive a type that supports <". The second one will let you pass a float64, which may be unexpected.) And I believe many Go users are happier because there is no operator overloading. > > > > I've yet to really feel the need for either of these (although i'm not a > > veteran golang dev -- only 1 year with golang in a professional > > environment), but I have come across scenarios where generics would > > otherwise be useful... (and function overloading, but that's a whole > > different kettle of fish) > > > > It's great that we've been given the chance to give some feedback :) > > I'm sorry, I'm not sure quite what you are saying. The reason for > constraints is to create a contract between the generic function and > its caller, so that far away code doesn't break unexpectedly. See > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraints > . > > Are you talking about type lists, rather than constraints? > > Ian > > -- > 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/CAOyqgcXfn3fpbQ5RXhB0f6EaYgyZbphtod24G%3DjxtzfEuF9SEA%40mail.gmail.com. -- 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/CAMV2Rqo72YaJm7uyZano8aSrZTAbv2iNH1Ofv4Xa67ZicUuWbQ%40mail.gmail.com.
