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.