variadic return results

[gopherbot]

by hugo.vincent:

From the docs:
"That ... represents the variadic argument list that in C would be handled
using the stdarg.h macros but in Go is passed using an empty interface
variable (interface {}) and then unpacked using the reflection library"

-- I think this concept should extend to return results, that is, there
should be a way a function can use reflection to see how many and what type
of arguments are expected by the caller. 

Perhaps, reflect could have functions like:
func (t *FuncType) NumOutExpectedByCaller() int
similar to:
func (t *FuncType) NumOut() int
and so forth.

This would be useful for solving the inconsistency with how error codes are
passed back as pseudo-optional return values and what happens when these
values are ignored. See mailing list thread "Re: [go-nuts] Re: Go needs
Exceptions", for example:
y = x.(Y) /* can panic the program */
y, _ = x.(Y) /* will never panic the program */

At the moment, the spec appears ambiguous or wrong. For example, the spec
and compiler allows code like this:
import (
    "fmt";
    "reflect"
)

func test(in ...) (out ...)
{
    out = in;
    return
}

func main()
{
    a := test(42);
    fmt.Print(reflect.Typeof(a), "\n");

    a = test("hello world", 123, 456, []int{1,2,3});
    fmt.Print(reflect.Typeof(a), "\n");

    // for comparison
    fmt.Print(reflect.Typeof(42), "\n");
}

Which gives (seemingly?) meaningless output:
main.dsigddd_1·1
main.dsigddd_3·3
int

Which revision are you sync'ed to? 4010:91c471680dc9

[rsc]

Comment 1:

Labels changed: added language-change.

Status changed to Thinking.

[rsc]

Comment 2:

Labels changed: added languagechange, removed language-change.

[robpike]

Comment 3:

This program actually does something, although nothing very useful:
====
package main
import (
    "reflect";
    "fmt";
)
func f(a ...) (b ...) { return a }
func main() {
    x := f(23, 45, 67);
    s := reflect.Indirect(reflect.NewValue(x)).(*reflect.StructValue);
    for i := 0; i < s.NumField(); i++ {
        fmt.Printf("%d %d\n", i, s.Field(i).Interface().(int));
    }
}
===
At the moment, the only way to assign to a ... variable (such as the return from f()) is
directly from another ... variable, more typically as an 
argument to a function call (consider fmt.Printf("%s\n", fmt.Sprintf("%d", 3))).
The pattern in your program and mine is an atypical consequence of the handling of ...
and does not imply a larger design goal. Allowing more 
general semantics to permit returning variant types from a function seems better handled
by providing an actual implementation of variant types, 
which is in our plans.
Regarding the result of printing reflect.Types, the result is always just a name.  For
compile-time generated anonymous types, those names may 
be unhelpful. If you were to look inside using reflection further, you'd see that it's
only the name that appears (but isn't) meaningless, as my 
program shows.

Status changed to WontFix.