The list of types supporting LessThan is not finite, is unbounded. The list of types supporting < is finite. But < could of been viewed as syntactic sugar if the Go designers so chose.
> On Jun 22, 2020, at 4:01 PM, burak serdar <bser...@computer.org> wrote: > > 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. -- 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/A1A60097-B68C-4679-A914-67D08B9319CD%40ix.netcom.com.
