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.
