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/CAOyqgcV5zGzOPZqZjGuTX7y%2BSn3jU-3f%2Buo4-i_0YOwYkuqfHQ%40mail.gmail.com.
