On Mon, Jun 22, 2020 at 6:06 PM Robert Engels <reng...@ix.netcom.com> wrote:
>
> 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.
If all you need to do is ==, then having an int or string (and not
float64) makes sense.
I have this JSON processing library that lets me treat JSON data like
DOM, with object, array and value nodes. The value nodes contain
interface{}, but I know it can only be json.Number, string, and bool
right after decoding. It wouldn've been nice to constrain the types
the JSON doc accepts to these three, so when, say, at some point in
the program someone tries to put an int as value it doesn't accept it.
>
> 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/CAMV2RqoyASbrP1vfeV62xvUYK-gBY480LtPDvhKZPo9rtp2Pfg%40mail.gmail.com.
