On Sunday, August 9, 2020 at 4:17:06 AM UTC+12, Ian Lance Taylor wrote: > > On Fri, Aug 7, 2020 at 6:54 PM Robert Engels <ren...@ix.netcom.com > <javascript:>> 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. >
I think that's a sound requirement. I suspect you're meaning a Min function that just handles the builtin integer types, but even one that handles floats as well is quite nice: https://go2goplay.golang.org/p/j9AYrSzrpE7 It would be very nice to see that type switch on T that you mention in the draft. (For one thing, it should allow replacing the bug prone "default" with "case float32, float64:" in my example.) Overall I think this latest draft is a big step forward. The [] syntax seems nicer too. Thanks for sticking with it. > > 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 <bse...@computer.org > <javascript:>> wrote: > > > > > > On Thu, Aug 6, 2020 at 1:17 PM Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > > >> > > >>> On Thu, Aug 6, 2020 at 12:10 PM Robert Engels <ren...@ix.netcom.com > <javascript:>> 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 <ia...@golang.org > <javascript:>> wrote: > > >>>> > > >>>> On Wed, Aug 5, 2020 at 8:52 PM Robert Engels <ren...@ix.netcom.com > <javascript:>> 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 golan...@googlegroups.com <javascript:>. > > >> 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/f641d7c6-37d9-49b8-a51e-8eb5b32776f5o%40googlegroups.com.
