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.
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).
You write the generic code using methods not operators in all cases.
How you define the methods gets tricky - no default casting in Go - but I think
you have that problem regardless.
It may be limiting in some cases but all of the common generic code is pretty
simple - mainly collections (with predicate filters).
You just don’t see a lot of code where the generic type is a number or a string
and the code does mathematical ops on the type.
> On Aug 5, 2020, at 10:05 PM, Ian Lance Taylor <i...@golang.org> wrote:
>
> On Wed, Aug 5, 2020 at 6:28 PM Robert Engels <reng...@ix.netcom.com> wrote:
>>
>> True, but cant Comparable be implemented by all built types? And Number be
>> implemented by numeric types? Sure, you can’t use the operators in generic
>> code but given most generic code is collections based it seems not a big
>> loss.
>
> The more you look into the details the more complex it becomes. For
> example, integer types support & and | but floating point types do
> not. Integer and floating point types support < but complex types do
> not. String types support + but not -. We have to choose between
> reflecting the language as it is, which requires a lot of new names
> all of which must be learned by every Go programmer, or leaving out
> the capability to write certain kinds of generic functions, which is
> OK for many people but frustrating for some.
>
> Or we can use type lists which doesn't add any new names and is sure
> to work for all cases, not only today but for any new primitive types.
>
> Ian
>
>
>
>>>> On Aug 5, 2020, at 4:30 PM, Ian Lance Taylor <i...@golang.org> wrote:
>>>
>>> On Tue, Aug 4, 2020 at 9:19 PM Robert Engels <reng...@ix.netcom.com> wrote:
>>>>
>>>> The operator support is what makes things so complicated. Why not define a
>>>> “numeric” type that has methods for all the operators that is used with
>>>> generics, similar to Number in Java. Then it is unified. If you are
>>>> writing specialized math performant code you would probably use concrete
>>>> types anyway.
>>>>
>>>> People complained about the boxing of primitives in Java but it was rarely
>>>> a problem in actual use - and then people fell back to specialized
>>>> structures anyway - which is what would happen here.
>>>
>>> Numbers are not the only primitive types in Go.
>>>
>>> Ian
>>>
>>>
>>>
>>>>>> On Aug 4, 2020, at 11:06 PM, Ian Lance Taylor <i...@golang.org> wrote:
>>>>>
>>>>> On Tue, Aug 4, 2020 at 7:31 PM Ben Hoyt <benh...@gmail.com> wrote:
>>>>>>
>>>>>>> Yes, I think that the ability to write generics using operators is not
>>>>>>> optional. As I've said before, there are some functions that must be
>>>>>>> possible to write using any plausible generics mechanism. One of them
>>>>>>> is the Min function that returns the smaller of two values of some
>>>>>>> ordered type. If we can't write that trivial function, our generics
>>>>>>> mechanism is not usable for practical code.
>>>>>>
>>>>>> I don't think that's quite true. You can write it, it's just not as
>>>>>> nice to use with builtin types:
>>>>>>
>>>>>> func Min[type T Lesser](a, b T) T {
>>>>>> if a.Less(b) {
>>>>>> return a
>>>>>> }
>>>>>> return b
>>>>>> }
>>>>>>
>>>>>> To use it with (for example) int, you need to write a wrapper type, for
>>>>>> example:
>>>>>>
>>>>>> type Int int
>>>>>> func (i Int) Less(j Int) bool { return i < j }
>>>>>>
>>>>>> And then call it like so:
>>>>>>
>>>>>> Min(Int(2), Int(3))
>>>>>>
>>>>>> It's not pretty, but it definitely works
>>>>>> (https://go2goplay.golang.org/p/i6Q3tF-QwgH). This was kind of the
>>>>>> situation with sort.Sort (until sort.Slice came along), so it doesn't
>>>>>> seem any worse than that. Or you could instead define a generic type
>>>>>> "Ord" instead of Int:
>>>>>>
>>>>>> type Ord[type T Ordered] T
>>>>>> func (i Ord[T]) Less(j Ord[T]) bool { return i < j }
>>>>>>
>>>>>> And use it like so:
>>>>>>
>>>>>> Min(Ord[int](2), Ord[int](3))
>>>>>>
>>>>>> Or if type inference were improved to handle that case:
>>>>>>
>>>>>> Min(Ord(2), Ord(3))
>>>>>>
>>>>>> It's not pretty, partly because you get an Int/Ord result instead of a
>>>>>> plain int, but not terrible either.
>>>>>>
>>>>>> So it seems to me it's not a case of "we can't write that trivial
>>>>>> function" -- it just requires a bit of type conversion.
>>>>>
>>>>> OK, fair enough.
>>>>>
>>>>> I'll be more specific: I think it's necessary that it be possible to
>>>>> write a Min function whose body is something similar to
>>>>>
>>>>> if a < b {
>>>>> return a
>>>>> }
>>>>> return b
>>>>>
>>>>> I think that any approach to generics that requires more complex code
>>>>> would simply be rejected by the community of Go programmers.
>>>>>
>>>>>
>>>>>> So either way
>>>>>> -- with your approach or this approach -- it's klunky for one of the
>>>>>> cases:
>>>>>>
>>>>>> 1) Assuming type lists and a function which takes a comparator func
>>>>>> like "func Min[type T](a, b T, less func(x, y T) bool) T" -- in this
>>>>>> case you have the klunkiness of having to import (or define)
>>>>>> "primitives" and specify the comparison func even when it's obvious:
>>>>>> Min(2, 4, primitives.Less)
>>>>>> 2) With no type lists and a function which takes a "lesser" like "func
>>>>>> Min[type T Lesser](a, b T) T" -- in this case you have the klunkiness
>>>>>> of having to use wrapper types, like we did with sort.Sort back in the
>>>>>> day.
>>>>>
>>>>> To be clear, when I discussed a function, I was only discussing that
>>>>> in contrast to a type with a required method. I did not mean to
>>>>> suggest that a function would be suitable for use with a primitive
>>>>> type that supports operators.
>>>>>
>>>>> 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/CAOyqgcWqoACJp97ZZhKecNVg-OdxVoUxNX_kZusp2-xmZRwnmw%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/C0207B5F-8120-4292-8B56-13DEA39B9B43%40ix.netcom.com.
