Why would you need to declare a type being int or string for instance? It seems it would only ever be because of built in operators or you would need type casting code to use them - which is what generics tries to avoid.
This is why Java’s boxed types and standard interfaces make generics far easier - and still performant due to JIT, intrinsics and inlining. I am still uncertain why Go doesn’t take the same approach (only allow interface types) using static analysis at compilation time. > On Jun 22, 2020, at 6:19 PM, burak serdar <bser...@computer.org> wrote: > > On Mon, Jun 22, 2020 at 4:04 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> 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. > > Actually, the list of types supporting LessThen contains only one > type: interface {LessThan() bool} > > I didn't see in the draft design a limitation on the types that can be > listed in a type list. So can a type list contain an interface? > > If that is the case, I will repeat my suggestion to take type lists > outside interfaces and make them their own construct. Maybe call it > something else, like typeconstraint: > > typecontstraint T int, string, OtherType > >> >>>> 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/CAMV2Rqo4mFU84Z2JNwi8Wk_vwW9EdCwrqn6NOJ3e68hdWFCgVA%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/90095AAA-1EDC-4108-880A-6B2C16851907%40ix.netcom.com.