On Thu, Aug 6, 2020 at 8:53 PM Ian Lance Taylor <i...@golang.org> wrote:
> 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.
Is there a need for that? I can't really imagine one.
That being said, in general I agree with you that type-lists allow you to
be more deliberate about the semantics of the operators.
I would actually come from the other direction and say that both `string`
and `int` have `+`, but both have clearly different meanings. And even
`uint`, `int` and `float64` have subtle differences in how `+` works (for
example: `float64` can have `a+b==a && b != 0`).
So, given that `+` has different meanings for different types, listing them
explicitly gives more control over the behavior you intend.
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/CAEkBMfE38-kjwQSaYKBw0JZ%3DywWn5HTNjc%2B9PVoaZ7qsOGnntw%40mail.gmail.com.
