On Fri, Aug 7, 2020 at 7: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.
More than 90% of all generic *Java* code is for collections, because
the way generics are implemented it is almost impossible to use them
for anything else in Java.
>
> > 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/CAMV2Rqp-A19V%2BuAppDU7itG1s3Dqt1ZqOMxke%3DVnDsQ%2BeidgWw%40mail.gmail.com.
