The current design draft in effect chooses your option (1): https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#embedded-type-parameter-methods . The program should print A A.

Please don't draw any conclusions from the behavior of the go2go tool. The support for embedding type parameters is a horrible bodge.

We should add this to our list of test cases, though.

I see. I read "any methods of the type parameter's constraint are promoted to be methods of the struct" as merely confirming that embedded type parameters participate in method promotion like any other embedded type, not as implying that type parameter methods effectively have depth 0 regardless of their depth on corresponding type arguments.

I think the current wording is fine for most Go developers, but I think advanced Go programmers (particularly Go tools developers) would benefit from an extra sentence clarifying this.

I think it's also worth calling this out since it's a case where generic functions intentionally behave differently than a simple textual expansion of type arguments. For example, I think most Go programmers would intuitively expect M1[A3] and M2 here to have the same behavior: https://go2goplay.golang.org/p/EE6ep60Hnti

Granted I don't think they'd intentionally write code exactly like that, but I can imagine someone doing a refactoring where they either introduce or remove type parameters, and then they're bit by some subtle change in semantics like in #41685.

Change https://golang.org/cl/283113 mentions this issue: design: type parameters: clarify depth of embedded type constraint methods

I was thinking about this some more last night / this morning, and I think for type identity we need to distinguish: (1) normal embedding of a type into a struct and (2) embedding a type into a struct via a type parameter. In particular, I think reflect.StructField needs something like a Bound Type field (holding the pure-interface subset of the type parameter's constraint) so that at runtime users of the reflection API can reconstruct the method/field promotion rules.

I think we can still allow conversions between those two cases, similar to how type identity rules for structs are relaxed for converting structs that have tagged fields. But I think they do need to be different types.

/cc @bcmills @findleyr for more generics subtleties

That sounds like an argument that we should not permit embedding type parameters.

Disallowing embedding of type parameters would nicely avoid the issue as well.

Disallowing embedding for now seems like a good idea. That would reduce the potential for mistakes in the initial spec, and we can always add support in a later version when we can dedicate more time to getting the (subtle) details right.

Relatedly, I think we should disallow type P[T any] T then, or at least disallow declaring methods on it. go/types2 typechecks this package, but cmd/go2go generates invalid code for it: https://go2goplay.golang.org/p/m0ooQYSN5sc

package main

type A[T any] T
func (A[T]) M() {}

var _ A[*int]
var _ A[interface{}]

func main() {}

Yes, we should clearly reject methods with receiver type P[T] or *P[T] for type P[T any] T, since the constraint any allows T to be an interface type.

(That seems like a separate bug.)

I think the common issue here is that different types have different rules for how they contribute methods/fields when embedded / used as an underlying type, and when they're allowed to be used as the underlying type of a defined type with declared methods.

Note that the issue with A[*int] is that you can't declare methods on defined types whose underlying type is a pointer. Also, maybe you were just emphasizing any because it's what I used in the example code, but every type constraint that doesn't contain a type list/set is satisfiable by an interface.

Another issue I realized this morning is A[struct { M int }] will fail, because of collision for the M selector.

I agree with what appears to be the consensus here: we should at least initially reject these ambiguous cases.

We have #45639, which is similar to the case of type P[T any] T. Should we use that issue to track "disallow type parameters as the RHS of a type declaration", and use this issue to track "disallow embedding type parameters"? That way we have separate issues for the presumably separate fixes.

@findleyr SGTM.

Change https://golang.org/cl/339651 mentions this issue: [dev.typeparams] go/types: embedded type cannot be a (pointer to) a type parameter