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. > 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/36120C05-7F10-40D3-834E-6AC3325CAD13%40ix.netcom.com.