~Type means the type set where the underlying type is Type, not struct{}. Type's underlying type is struct{}, not Type, so it doesn't satisfy the interface. This is also true for non-struct type, e.g. https://go.dev/play/p/X6mE1QQGDlJ

~Type means the type set where the underlying type is Type, not struct{}. Type's underlying type is struct{}, not Type, so it doesn't satisfy the interface. This is also true for non-struct type, e.g. https://go.dev/play/p/X6mE1QQGDlJ

I don't know what is the correct understanding for this. Your example seems align with your provided interpretation. The following example is also confusing because it feels like it is impossible to limit the type parameters to a slice that its element's "underlying" type is Type:

package main

type Type struct{}

type MyType Type

func main() {
	x := []Type{}
	y := []MyType{}
	F1(x) // OK

	F1(y) // ERROR: MyType does not implement Type
	F2(y) // ERROR: cannot implement ~Type (empty type set)
	F3(y) // ERROR: MyType does not implement interface{struct{}} (possibly missing ~ for struct{} in constraint interface{struct{}})
}

func F1[S []Elem, Elem Type](t S) {}

func F2[S []Elem, Elem ~Type](t S) {} // ERROR: invalid use of ~ (underlying type of Type is struct{})

func F3[S []Elem, Elem interface{ struct{} }](t S) {}

it feels like it is impossible to limit the type parameters to a slice that its element's "underlying" type is Type

Yeah, same issue. It is impossible because there is no type whose underlying type is Type. The underlying type of both Type and MyType is struct{}.

F3 would work if you use ~struct{}.

OK the trick is to use ~ in struct{}:

func F4[S []Elem, Elem interface{ ~struct{} }](t S) {}

F4(y) // OK

But what if it is a struct that we can't easily write? Does that mean we must provide and declare the nested struct in the type parameter? What if it is a circular struct?

func F5[S []Elem, Elem ~struct { /* Next *CircularType??? */ ](t S) {}

type CircularType struct {
	Next *CircularType
}

F5([]CircularType{})

Edit: What if there is a field typed in an unexported type?

I think ~struct { Next *CircularType } actually works. https://go.dev/play/p/Bw3Y4Pya_nX . I agree it is a bit awkward.

I don't know what to do with unexported fields.

Do you have a real use case that you need to define the element type with a different name? (i.e. use []MyType instead of just []Type ?)

Do you have a real use case that you need to define the element type with a different name? (i.e. use []MyType instead of just []Type ?)

I don't know how to answer what could be a real use case, but I am trying to write code like this:

A polygon mesh structure that consists of a slice of polygons:

type PolygonMesh struct { Faces []Polygon }

type Polygon struct {
    verts []Vertex
    ....
}

A specialized polygon, triangle, or quad has some sort of specialized implementation for polygons, such as computing normals, etc.

type Triangle Polygon

func (t Triangle) Normal() Vec3 { /* ... do stuff with vertices */ }

type Quad Polygon

... more specialized methods ...

There are also specialized polygon mesh structures:

type TriangleMesh struct { Faces []Triangles }
type QuadMesh struct     { Faces []Quad }

Now, I am expecting an iterator over all faces:

package mesh

func IterateFaces[F []Elem, Elem ~Polygon](faces F) { ... }

So that on the caller side:

mesh.IterateFaces(TriangleMesh{}.Faces)
mesh.IterateFaces(QuadMesh{}.Faces)
mesh.IterateFaces(PolygonMesh{}.Faces)

Thanks. Would it be possible to define Polygon an alias type, i.e. type Polygon = struct { verts []Vertex; ... }? Then I think ~Polygon would work. (But you cannot define methods on Polygon, then.)

If you believe there is a missing feature and it is useful to add the support, you are welcome to file a proposal (or modify this issue to a proposal) to change the language spec. (With the current spec, I think the compiler is correct.) Thanks.

Would it be possible to define Polygon an alias type, i.e. type Polygon = struct { verts []Vertex; ... }? Then I think ~Polygon would work. (But you cannot define methods on Polygon, then.)

I don't think it is possible to define as an alias because Polygon also its own specialized methods. Moreover, the Polygon struct itself will have circular fields pointing to another polygon, and so on. This is not a made up need but actually from research. I could also imagine in an abstract way that a similar need will happen as described on top of the issue. But I guess my provided case should be enough.

I don't have an idea about what a proposal could be. Sigh for this confusion.

Another possible workaround would be, instead of defining Triangle etc. as type Triangle Polygon, embed Polygon in them, i.e. type Triangle struct { Polygon }. Then you might be able to use ~struct { Polygon } as the constraint for generic functions? (I didn't try it myself.)

I guess one idea that you could potentially proposing is to change the type set ~T not to mean types whose underlying type is T, but types whose underlying type is the underlying type of T (or use a different notation than ~T for it), if you think that's helpful.