Thank you for filing this issue @loren-osborn and welcome to the Go project!

@griesemer @mdempsky, what do y'all think of these suggestions?
a)

missing type for argument bar (can only use ... with final parameter in list)

b)

missing type for argument bar

b) is succinct but will likely generate more confusion say if the function signature contains more than one such repeated field e.g.

func Foo(bar, foo, fizz, args ...interface{}) {
}

Hence I am leaning towards suggestion a) which will print out

missing type for argument bar (can only use ... with final parameter in list)
missing type for argument foo (can only use ... with final parameter in list)
missing type for argument fizz (can only use ... with final parameter in list)

or later on, perhaps after the frontend overhaul we can provide a more concise message

missing type for arguments bar, foo, fizz: ... can only be used for the final parameter

Thank you for the report.

I agree that the error message can be improved. Certainly, the error's column number information should at least point at the non-final parameter in question, and probably the parameter's name can be incorporated into the error message. I think these would address the raised issue about users misfocusing on args ...interface{} instead of bar.

However, I disagree with the proposed "missing type" wording. In the linked example (https://play.golang.org/p/2EFkTjC3KhA), bar does have a type: ...interface{}. The error is just that this type is invalid, because bar is not the final parameter.

I'd probably lean towards changing the error message to:

cannot use ... with non-final parameter bar

Not urgent. Good starter project.

@mdempsky, I almost agree. The problem is that ...interface{} isn’t a type. The type of args is actually []interface{} imparted by the ... variadic operator. If this operator was defined to only ever apply to one argument, then bar wouldn’t have a type, and the error message I suggested would make sense. I’m not opposed to your suggested error message, I just feel it’s another solution to the same problem.

Change https://golang.org/cl/152417 mentions this issue: cmd/compile: improve error message for non-final variadic parameter

Change https://golang.org/cl/152758 mentions this issue: cmd/compile: avoid multiple errors regarding misuse of ... in signatures