On Thu, Aug 20, 2020, 11:22 PM Bakul Shah <ba...@iitbombay.org> wrote:
> On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor <i...@golang.org> wrote:
>
> > 3.
> >
> > We’re going to clarify that when considering the operations permitted
> > for a value whose type is a type parameter, we will ignore the methods
> > of any types in the type list. The general rule is that the generic
> > function can use any operation permitted by every type in the type
> > list. However, this will only apply to operators and predeclared
> > functions (such as "len" and "cap"). It won’t apply to methods, for
> > the case where the type list includes a list of types that all define
> > some method. Any methods must be listed separately in the interface
> > type, not inherited from the type list.
> >
> > This rule seems generally clear, and avoids some complex reasoning
> > involving type lists that include structs with embedded type
> > parameters.
>
> You seem to be saying a generic function can use operator X only if
> if *every* type in the type list implements it. Thus if I have
>
> type foo interface { int; someSLice }
>
> I can't use + and I can't use len(), right?
Right. And, to be clear, that is how the current design draft works before
this change.
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/CAOyqgcUd2yLB-MhFAkuiyuoBp7e15pMkAz0HMmNPE9p20gvBmg%40mail.gmail.com.
