I believe that:

then within f the type of p is equivalent to type []T.

and

If the final argument is assignable to a slice type []T and is followed by ..., it is passed unchanged as the value for a ...T parameter. In this case no new slice is created.

together is sufficient to define the current behavior as working as intended.
Note that spread only applies with an exact type match, not just with assignable elements.

@seankhliao I am not sure I understand you I think. I don't want to debate the decision, just understand it better.

Consider this:

	F(aSlice[0], aSlice[1])   // this is fine (A)
	F(aSlice...) // BUG: error: cannot use aSlice (variable of type []A) as []I value in argument to F (B)

Isn't that strange? To me it is, but maybe I am expecting to much of the spread operator.

Please note that there are two questions:

1. Is this indeed intended behaviour as per the specification; if so, should this be made clearer?
2. If this is indeed intended behaviour, why is that so? Would it make sense to propose (B) to also work?

I am just curious to know if I miss something obvious for why (B) is not needed or is not a good idea.

Thank you!

F(aSlice[0], aSlice[1]) creates a new slice and assigns to its first two elements the corresponding arguments from aSlice, so the individual elements of aSlice need to be assignable to the element type of the argument. F(aSlice...) passes aSlice itself as the argument, so its (slice) type needs to be assignable to the argument itself. This is described in Passing arguments to ... parameters. https://go.dev/doc/faq#convert_slice_of_interface explains further why (B) cannot work.

@zephyrtronium Thanks, it is clear now. I misinterpreted "..." as an actual (spread) operator, while it is not.

Since a new slice is created for individual arguments given to a variadic function call, could this also not be done if those arguments come from a "...T" construct instruct instead?

I suspect the reason might be that with actual individual arguments the size of the array backing the slice is known at compile time and so can be statically allocated. Allowing this with "...T" would potentially do huge dynamic array allocation.

But from a language perspective it feels a bit weird not being able to do it, might be just me of course.

EDIT: (added an extra note)

Converting []T to []interface{} is disallowed as described here: https://go.dev/doc/faq#convert_slice_of_interface
The reason is that a copy must be made. But for variadic arguments a copy is made if individual arguments are given anyway. Plus the ... in "T..." gives a explicit indication that said copy is made, if this were allowed.