[go-nuts] [generics] Type embedding in generic types

In the context of Type Parameters - Draft Design#generic-types : Type embedding is allowed in the proposed generic changes. Oddly, the current implementation allows for calling methods in

Re: [go-nuts] [generics] Type embedding in generic types

. Thanks Ian. On Monday, July 13, 2020 at 7:03:35 PM UTC+2 Ian Lance Taylor wrote: > On Mon, Jul 13, 2020 at 9:15 AM 'Javier Zunzunegui' via golang-nuts > wrote: > > > > In the context of Type Parameters - Draft Design#generic-types: > > > > Type embe

Re: [go-nuts] [generics] Type embedding in generic types

will > postpone this debate while I focus on other parts of the proposal and gain > some more experience using the go2 branch. Not calling for any action here > at this point. Thanks Ian. > On Monday, July 13, 2020 at 7:03:35 PM UTC+2 Ian Lance Taylor wrote: > >> On Mon, J

Re: [go-nuts] [generics] Type embedding in generic types

would be something *good*. But I do think it adds more > type-safety and that does provide value. > > Interested to hear your thoughts :) > > Axel > > > On Mon, Jul 20, 2020 at 3:37 PM 'Javier Zunzunegui' via golang-nuts < > golan...@googlegroups.com> wro

Re: [go-nuts] [generics] Type embedding in generic types

ould you agree > that your statement "it adds complexity without adding value" doesn't > really hold up? > > On Tue, Jul 21, 2020 at 9:46 AM 'Javier Zunzunegui' via golang-nuts < > golan...@googlegroups.com> wrote: > >> >> Thanks f

Re: [go-nuts] [generics] Type embedding in generic types

you end up with a brittle multiple inheritance problem. > > Or you need language support for typed TLS and remove Context entirely. > > On Jul 21, 2020, at 6:24 AM, 'Axel Wagner' via golang-nuts < > golan...@googlegroups.com> wrote: > >  > > O

[go-nuts] Interface definition as type alias

TLDR: Why should I NOT the alias form `type ... = interface {...}` instead of the standard `type ... interface {...}` for interface declarations? The extended question: The normal type definition for an interface in go would be `type TypeName interface {...}`. This results in a new type, which

[go-nuts] Re: Interface definition as type alias

> So yes: Using a type alias has advantages, but no, this advantage is never realized because neither the alias nor the plain type decl are used in practice. The ResonseWriter is a bad example because it has a method `Header() http.Header`, for which you must import net/http regardless. Take f

[go-nuts] Re: Interface definition as type alias

> The only real downsides, I think, are that compiler errors gets harder to read: > https://github.com/golang/go/issues/21866 > And likewise, that the name won't appear at runtime, so if you print things using `reflect`, the result will be less readable. > ... > https://github.com/golang/go/issue