On second thought, that would lead to ‘operator overloading’ and the abuses it
invites - so oh well - I guess we write duplicate methods based on types -
which is pretty much what you can do now - write a base implementation using
interface{} and then a small wrapper struct that types it. Given that, based on
the current proposal, I go back to the position that Go doesn’t need generics.
> On Aug 8, 2020, at 11:43 AM, Robert Engels <reng...@ix.netcom.com> wrote:
>
> Understood. Even if you keep operators they could be mapped to certain built
> in interface methods. C++ has operator loading, Java does not (except for
> auto-boxing) It seems Go generics are trying to play in the middle and I
> think the end result is going to lead to confusing code, but we shall see.
>
>> On Aug 8, 2020, at 11:16 AM, Ian Lance Taylor <i...@golang.org> wrote:
>>
>> On Fri, Aug 7, 2020 at 6:54 PM Robert Engels <reng...@ix.netcom.com> 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.
>>
>> 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 <bser...@computer.org> wrote:
>>>>
>>>> On Thu, Aug 6, 2020 at 1:17 PM Ian Lance Taylor <i...@golang.org> wrote:
>>>>>
>>>>>> On Thu, Aug 6, 2020 at 12:10 PM Robert Engels <reng...@ix.netcom.com>
>>>>>> 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 <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/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/CAOyqgcWoeG%3DC68c-kr10ED7u-jFasx14vhzhuwCOmpN-uNWuTw%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/2334DC45-CE7D-4A45-A257-BEF6AFCFE842%40ix.netcom.com.
