CC @golang/compiler, perhaps @griesemer specifically?

Simpler case (playground):

package p

type T[E any] int

func (T[E]) m(T[[]E]) {}

This is working as intended. Since the type parameter E is not used, you can simply remove it and the code will compile.

If the type parameter were used, this code couldn't be compiled, at least with the current implementation of Go which monomorphizes code (doesn't box generics): say, T is instantiated with int. That means it will have a method m(T[[]int]) producing a type T instantiated with []int. That type will have a method m(T[[][]int]). Which will give rise to that new type T[[][]int], etc. ad infinitum. Code generation would never stop.

PS:The monomorphization check doesn't consider whether a type parameter is used or not.

@mdempsky In case you want to add something to this.

I agree the error here is expected and the monomorpic checker is working as intended.

@griesemer Thank for your explain. But I still have some doubts.

Is the limitation here caused by the current implementation of generics, or will there always be this limitation. Or as the generics iterate, this limitation will disappear.

If this restriction will disappear in the future, when will it happen and whether it will rely on other preparatory work? If this restriction will be lifted in the future, should this issue be kept open?

In addition, I have not encountered similar problems in other languages. I am not sure about the implementation in go, but I believe this can be solved.

Going back to the original proposition, that is to say, I have no way to implement the chunk method on slice?

So is there any compromise way to implement chunks? It doesn't involve implementing a lot of top-level functions.

I'm not sure I understand the unused E above.

The following example uses E, but still reports an error:

type slice[E any] struct{ elems []E }

func (s slice[E]) chunk(n int) slice[[]E] {
	return slice[[]E]{elems: [][]E{}}
}

Is the limitation here caused by the current implementation of generics, or will there always be this limitation.

We want to ensure instantiation is guaranteed to reach a finite fixed point. If instantiating type T[X] requires instantiating type T[[]X], then we'll need T[[][]X], and so on. It never stops.

@leaxoy The limitation could (perhaps) be removed if we'd always box generic values. But because our implementation uses a hybrid approach that monomorphizes code (generates code for each kind of type, for speed), your source would lead to endless code generation as @mdempsky pointed out. There are no plans to change this.

Your chunk implementation can be written like so:

func chunk[E any](s []E, n int) [][]E {
	do something sensible here
}

It's not a method but it also doesn't refer to itself anymore.

func chunk[E any](s []E, n int) [][]E {
	do something sensible here
}

But this break method chaining, maybe pipe-operator like cpp's ranges can solve user experience problems to a certain extent, but it's a separate topic.