I'm not completely sure what you are saying, but I think you may be misreading the paragraph in the spec. The spec says that if you write variadic([]int{1,2,3}...), with the trailing ..., then the slice will be passed unchanged to the variadic function. That is only permitted if the slice is assignable to []T, where T is the variadic type, in your case interface{}. Since []int is not assignable to []interface{}, as you know, the use of the trailing ... in the call is forbidden. So compilation fails, as it should.

It sounds like you may be saying that by using the trailing ..., you are suggesting that the compiler should unpack the slice rather than passing it directly. But that is not what the trailing ... means. The trailing ... means to pass the slice directly. The compiler doesn't implement that differently based on whether the slice is assignable to []T or not.

Closing because this is indeed working as intended.

You may want to read the discussion in #18605.

If ... means to pass as-is then this should be clearly mentioned in the spec (I could not find the actual definition of ... other than it being an operator). General consensus however seems to be that ... is the "unpack operator", comparable to other languages. This would imply that it unpacks, which it does not.

In addition, the way that the FAQ section is worded suggests that if slice []A cannot be assigned to slice []B:

Otherwise, the value passed is a new slice of type []T with a new underlying array whose successive elements are the actual arguments, which all must be assignable to T.

I don't see the creation of that new slice happening, which is why I reported it. If not a defect in ... operation, it is a defect in the FAQ for not being clear what operator ... actually does.

From what I understand #18605 appears to propose adding support for variadic(int(1), []int{2,3,4}). While nice to have, it is something else and not the issue I was reporting.

I mentioned #18605 because the discussion on that issue discusses the point about slices being passed directly.

The language spec says, in the section "Passing arguments to ... parameters", "If the final argument is assignable to a slice type []T, it may be passed unchanged as the value for a ...T parameter if the argument is followed by .... In this case no new slice is created" (https://golang.org/ref/spec#Passing_arguments_to_..._parameters). That seems precise to me: if the final argument is followed by ..., no new slice is created. I'm not sure what general consensus says that ... is the unpack operator; I don't think it can reasonably be described that way.

The second of the spec that you quote above, which discusses a new slice, is the section in which the arguments are passed individually, without using ....