On Fri, Aug 7, 2020 at 6:54 PM Robert Engels <reng...@ix.netcom.com> wrote:
>
> I’d really like to see an example of generic code that takes both string and
> numeric types that uses operators. Sorting/searching is one but as I already
> said the built in string operators are not sufficient for collation cases.
>
> Even generic code that “only works on unsigned types”.
>
> More than 90% of all generic code is collections. Operators are not needed
> for these.
I don't think I have anything useful to add to what I've said already
on this topic.
I believe that being able to write a Min function in ordinary Go is an
absolute requirement for generics in Go. Full stop.
It would be great to hear about any fatal problems that type lists
have. It would be great to hear about alternative approaches that
support operators. I don't think it's useful to debate whether we
need to be able to use operators in generic code.
Ian
> > On Aug 6, 2020, at 2:45 PM, burak serdar <bser...@computer.org> wrote:
> >
> > On Thu, Aug 6, 2020 at 1:17 PM Ian Lance Taylor <i...@golang.org> wrote:
> >>
> >>> On Thu, Aug 6, 2020 at 12:10 PM Robert Engels <reng...@ix.netcom.com>
> >>> wrote:
> >>>
> >>> We’ll probably agree to disagree there. Java has a lot of generic code
> >>> written and it’s never been a problem (using methods). Rarely can you
> >>> write code that treats + the same no matter if passed a string or numeric.
> >>>
> >>> Even operators like < with strings don’t really make a lot of sense
> >>> because different collations are used.
> >>>
> >>> I think having a higher bar for Go generic implementations is fine -
> >>> writing generic code properly is harder than regular Go - there’s much
> >>> more to resin about.
> >>
> >> I hope that is not the case.
> >>
> >> Also, it's important that it be easy to read generic code. We can put
> >> extra burdens on writers of generic code if necessary, but we must
> >> make the burden on readers of generic code as small as we possibly
> >> can.
> >>
> >> And again: is the complexity from requiring methods rather than
> >> operators really less than the complexity of using type lists?
> >
> > There are things you can do with type lists that you cannot do with
> > operators. You can limit a function to run on unsigned numbers, for
> > instance. I think it also makes it explicit to the reader that
> > a.Add(b) is possibly more complicated than a+b.
> >
> >>
> >> Ian
> >>
> >>
> >>
> >>>> On Aug 6, 2020, at 1:53 PM, Ian Lance Taylor <i...@golang.org> wrote:
> >>>>
> >>>> On Wed, Aug 5, 2020 at 8:52 PM Robert Engels <reng...@ix.netcom.com>
> >>>> wrote:
> >>>>>
> >>>>> I understand your point, but I think a few minor corrections Make a
> >>>>> difference - it does not matter that String supports + and not - , a
> >>>>> string would not be a Number. String concatenation is not addition.
> >>>>
> >>>> My point wasn't that a string is a number. My point was that the
> >>>> current design draft permits writing a function that uses + and works
> >>>> with both strings and numbers. If we adopt something along the lines
> >>>> of what you are suggesting, we must either define a name for "types
> >>>> that support +" or we must say "you can't write a generic function
> >>>> that uses + and works with both strings and numbers."
> >>>>
> >>>>
> >>>>> There are also several ways to implement “ordering” with complex
> >>>>> numbers, even between complex and rational - it’s all a matter of
> >>>>> definition. There is also the possibility to make complex not a
> >>>>> Comparable (compile time failure).
> >>>>
> >>>> In Go, the types complex64 and complex128 do not support the < <= >= >
> >>>> operators. That is what I mean when I say that the complex types are
> >>>> not ordered. I'm not sure it matters that it is possible to define
> >>>> some ordering on complex numbers; the point is that the language
> >>>> defines no such ordering, so if you need to use ordering operators you
> >>>> can't use complex types.
> >>>>
> >>>>
> >>>>> You write the generic code using methods not operators in all cases.
> >>>>
> >>>> Ah, I didn't understand that. I think that is a non-starter. I think
> >>>> it is a requirement that people be able to write (and read) Min as
> >>>>
> >>>> if a < b {
> >>>> return a
> >>>> }
> >>>> return b
> >>>>
> >>>> Saying that you must write this as, e.g.,
> >>>>
> >>>> if a.Less(b) {
> >>>> return a
> >>>> }
> >>>> return b
> >>>>
> >>>> means that the generic language is not the normal language. That adds
> >>>> a massive layer of complexity to using generics: you can no longer
> >>>> write ordinary Go code for generic functions, you have to write in
> >>>> this alternative language that is harder to write and harder to read.
> >>>> You also have to remember a bunch of names for the methods that
> >>>> correspond to the operators. The design draft works very hard to
> >>>> avoid these issues.
> >>>>
> >>>> In particular, I think that making that requirement would be adding
> >>>> much more complexity to the language than we get by adding type lists.
> >>>>
> >>>> 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/CAOyqgcWuPNgz%2B1Yz71_xpq6sHEw77EXYhcmSFwQAwE7iZhV5bw%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/CAOyqgcWoeG%3DC68c-kr10ED7u-jFasx14vhzhuwCOmpN-uNWuTw%40mail.gmail.com.
