Maybe `type list` equals to `sum type`
type SignedInteger interface {
type int, int8, int16, int32, int64
}
can replaced by
type SignedInteger int|int8|int16|int32|int64
func max[type I SignedInteger](a I, b I) I {
if a > b { return a }
return b
}
在2020年8月9日星期日 UTC+8 下午11:54:38<ren...@ix.netcom.com> 写道：
> 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 <ren...@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 <ia...@golang.org> wrote:
> >>
> >> On Fri, Aug 7, 2020 at 6:54 PM Robert Engels <ren...@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 <bse...@computer.org>
> wrote:
> >>>>
> >>>> On Thu, Aug 6, 2020 at 1:17 PM Ian Lance Taylor <ia...@golang.org>
> wrote:
> >>>>>
> >>>>>> On Thu, Aug 6, 2020 at 12:10 PM Robert Engels <ren...@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 <ia...@golang.org>
> wrote:
> >>>>>>>
> >>>>>>> On Wed, Aug 5, 2020 at 8:52 PM Robert Engels <
> ren...@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...@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...@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/f422e0ea-524e-47f4-a4ca-7ea0fb943afbn%40googlegroups.com.
