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

2020-07-21 Thread 'Javier Zunzunegui' via golang-nuts
I suggest we move the discussion about Axel's post to reddit . Let's keep this exclusively on the the topic of embeding + generics. For anyone joining here, the main arguments are in the 4th post here

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

2020-07-21 Thread Robert Engels
The Context problem is more easily solved using package namespaces for keys with conventions rather than type embedding. Otherwise 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,

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

2020-07-21 Thread 'Axel Wagner' via golang-nuts
On Tue, Jul 21, 2020 at 10:54 AM 'Javier Zunzunegui' via golang-nuts < golang-nuts@googlegroups.com> wrote: > It's not A(B,C,D) vs A(B(C(D))), both are supported with & without > embedding. My issue is with a linked list that requires a new type for each > additional node. It is potentially an

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

2020-07-21 Thread 'Javier Zunzunegui' via golang-nuts
It's not A(B,C,D) vs A(B(C(D))), both are supported with & without embedding. My issue is with a linked list that requires a new type for each additional node. It is potentially an explosion of types, an imho an abuse of the type system. > At the end of the day, though, my main point was

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

2020-07-21 Thread 'Axel Wagner' via golang-nuts
Why do you feel that a type A(B, C, D, E) should be supported, but A(B(C(D(E))) shouldn't? They are equivalent in expressiveness. And to be clear, I'd also prefer A(B, C, D, E) for this use, but ISTM this isn't possible without variadic type-parameters (i.e. I'd need a way to express "this

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

2020-07-21 Thread 'Javier Zunzunegui' via golang-nuts
Thanks for sharing Axel. I would place your post firmly in the category "doing something wild and can't use generics for it". Philosophical issues around context aside, it implements the chain of contexts directly via the type system, e.g.the TYPE after N wraps is `FooContext(BarContext(... N

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

2020-07-20 Thread 'Axel Wagner' via golang-nuts
Hi, given the discussion here, the blog post I just published might be interesting: https://blog.merovius.de/2020/07/20/parametric-context.html To the best of my knowledge, what I describe there is only really doable using embedded type-parameters. As I state in the conclusion, I'm not entirely

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

2020-07-20 Thread 'Javier Zunzunegui' via golang-nuts
Coming back at this after more thought & exploration. The fundamental problem I see is it introduces complexity, but no value. Say `type I interface {...}` `type S(type T I) struct {T}` Then the generic S (before instantiating with a particular T) may implement any interface, e.g. in any

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

2020-07-14 Thread 'Javier Zunzunegui' via golang-nuts
Issue openned in https://github.com/golang/go/issues/40199. Still clarifying my thoughts on embedding types within generics, 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.

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

2020-07-13 Thread Ian Lance Taylor
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 embedding is allowed in the proposed generic changes. Oddly, the current > implementation allows for calling methods in the embedded types but

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

2020-07-13 Thread 'Javier Zunzunegui' via golang-nuts
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