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. > 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/3D86913B-898B-40B0-B738-047423DF1423%40ix.netcom.com.