proposal: spec: Allow passing more arguments to variadic functions with final argv...

[navytux]

Hello up there. Currently the following does not compile:

import "log"

func myprint(subject string, argv ...interface{}) {
        log.Print(subject, argv...)
}

and gives

./argv.go:6:11: too many arguments in call to log.Print
        have (string, []interface {}...)
        want (...interface {})

to make it work one has to change myprint as follows:

func myprint(subject string, argv ...interface{}) {
        log.Print(append([]interface{}{subject}, argv...)...)
}

which adds much noise to actual signal.

For variadic functions the language already implicitly allocates argv slice as it happens e.g. in the following log.Print call:

log.Print(1, 2, 3, 4, "hello")
// ^^^ compiler implicitly allocates argv := []interface{}{1, 2, 3, 4, "hello"}
// and essentially passes that argv to log.Print

So from this point of view implicitly allocating new argv2 = append([]interface{}{subject}, argv...) for (subject, argv...) case should be consistent.

---

I propose: for variadic functions with signature ...T allow merging extra arguments with final argv... if all extra arguments are assignable to T and argv is assignable to []T. If both extra argumens and final argv... are present, a new []T slice is allocated and passed to called function. The content of passed slice is append([]T{extra1, extra2, ..., extraN}, argv...).

Thanks beforehand,
Kirill

[josharian]

Possible dup of #18605.

[cznic]

Replace your

func myprint(subject string, argv ...interface{}) {
        log.Print(append([]interface{}{subject}, argv...)...)
}

with

func myprint(subject string, argv ...interface{}) {
        log.Printf("%s %v", subject, argv...)
}

But you can do that directly w/o any myprintf.

[navytux]

@cznic: log.Print was just an example. The actual case where I hit this was not about log.Print and there was no ...f helpers ready. E.g. it is when you have to use glog.InfoDepth and many other cases. The issue here is about the language, not particular logging case.

@josharian thanks for the pointer. Looks like this could be generalized to (extra1, extra2, argv1..., extra3, argv2..., extra4, argv3...).

I appologize for missing original issue.

[mdempsky]

Closing as dup of #18605.