This code is accepted by the type checker. Of course, when you use p := BaseData{}, the p.Foo() call will fail as in that case that Foo method is not present.

There is a an issue with the translator.

But there is also a question as to whether this should be permitted in the first place: If Base is locally instantiated (inside a function) with a type parameter from the enclosing function, it's not exactly clear what that means with respect to methods. Does B have the methods of the constraint associated with the enclosing function's type parameter? (Right now the type checker ignores those). There are various open questions around such scenarios that we need to understand better.

First of all, I fail to see why p := BaseData{}, p.Foo() should fail, since BaseData, IMO, should have the method Foo, from the declaration func (b Base(T)) Foo(). I find it counter-intuitive with my experience from other programming languages that this is not the case.

I think "what it should mean" for my example depends on practical use. I think this should be permitted, because this would be extremely handy in several situations. For example; imagine a GUI library where I have a generic type Widget (type T) { T ; WidgetData }, with many methods defined generically on Widget(T). It would be very natural, and convenient to be able to write type Button Widget(ButtonData), and then be able to use all the generic Widget methods on Button as well, as a form of "static inheritance".

This is the minimal program that has the issue:
https://go2goplay.golang.org/p/3SsjcAKB0A9

package main

type Base(type Embed) struct {
	Embed // Embed // Remove the first pair of // to make it compile
}

type Data struct {
}

func main() {
	_ = Base(Data){}
}

@beoran BaseData is a declared as a new, defined type, with the underlying type being the underlying type of Base(Data). Even in regular Go, new, defined types don't inherit the methods associated with the defined type the declaration has on the RHS (they only get methods that might be present through embedding in that RHS type). And in this case, Foo is associated with Base. So this seems to be working as one would expect.

Your minimal program that has the issue is valid and accepted by the type checker; this is still a translator issue. (That is, it type-checks with Embed as an embedded field.)

Finally, regarding what it should mean: Naturally, we want to define the meaning in a way that is useful. But we also have existing rules in Go, and it may well be that some of the semantics that we are trying to define for type parameters actually follows from existing rules. We are still exploring this. For instance, some of the modeling of type parameters in the type checker, based on "usefulness", turned out to be incorrect as it lead to inconsistencies.

Thanks for your explanation. I realize that misunderstood. What I want to do is type BaseData = Base(Data), however, iirc, this is not allowed with the current design, although I think it would be useful.

And yes, consistency is important.

Therefore, for this issue, let's focus on the problem with the translator, and see how we can fix this.

Change https://golang.org/cl/238857 mentions this issue: [dev.go2go] go/go2go: handle fields promoted through embedded type parameter

This is now fixed on the dev.go2go branch.

I doubt that I have all the cases right here, but at least this case should now work.