proposal: spec: allow conversion between return types and structs

[urandom]

This comes from a conversation in #32941

The goal of this proposal is to allow easy conversion from a function return to a struct with the same field types and order.

This would allow to more easily pass a function result to a channel, without having to manually create temporary variables and filing them up in a struct before it is sent thorough a channel.

Example :

type Pair struct {
    i int
    s string
}

func F() (int, string) { ... }
func G() chan {
    Pair c := make(chan Pair) 
    go func() { c <- Pair(F()) }() 
    return c 
}

Like converting between structs, tags should be ignored

[tema3210]

As example we can have:

type T struct {
          i string,
          i2 int,
}
type T2 tuple (string,int)
func A() (string,int) {...}

And in another function:

func main() {
          var a T
          var b T2
          a = A() //valid, with this proposal
          b = A() //valid, with another proposal
          d,c := A() //valid, currently
}

Another proposal is: #32941
We can add the tuple type, all this conversions, return type will still be multiple return,but tuple will be constructed in place, then converted to the struct(or just saved).

However this is related features, i don't see any valuable benefits of adding these features aside.

[bcmills]

There is an interesting duality for function arguments: today it is possible to pass the results of a multi-result function directly to another function that accepts the same argument list (https://play.golang.org/p/f3kNTppbVMc).

Should it be possible to make such a call by unpacking a struct?

If so, arguably that should require explicit syntax — what would it look like?

[tema3210]

There is an interesting duality for function arguments: today it is possible to pass the results of a multi-result function directly to another function that accepts the same argument list (https://play.golang.org/p/f3kNTppbVMc).

Should it be possible to make such a call by unpacking a struct?

If so, arguably that should require explicit syntax — what would it look like?

Technically, yes, but I don't think that it's good idea. Readability will be almost lost(due to required declaration reading).

Personally I can't imagine syntax.

[urandom]

This proposal does not discuss assignability, only convertibility. The example @tema3210 would actually be invalid, as the proposal currently stands.

That being said, I don't see anything preventing a future discussion on assignability. Nevertheless, as for a hypothetical expansion syntax, why not just use ... ?

[bradfitz]

Should it be possible to make such a call by unpacking a struct?

If so, arguably that should require explicit syntax — what would it look like?

I was proposing to @griesemer that maybe we also use ... to unpack a struct in a call:

type Pair { x, y int }
func f(a, b int) {}
func main() {
    var p Pair
    f(p...)
}

Or even:

   s := struct{_ int; _ int; _ string}{1, 2, "foo"}
   x, y, z := s...

[bradfitz]

And maybe using struct(...) to convert an arbitrary function call return (or literals too?) into an unnamed struct:

func f() (int, int, string) { return 1, 2, "foo"}
func g() (x int, y int, N string) { return 1, 2, "foo"}
func main() {
     fmt.Printf("%T\n", struct(f())) // struct { _ int; _ int; _ string }
     fmt.Printf("%T\n", struct(g())) // struct { x int; y int; N string }
     y := struct(1, 1.0, "foo")
     fmt.Printf("%T\n", y) // struct { _ int; _ float64; _ string }
}

But then you have issues of naming the struct fields. If you converted an interface method call into a struct, you'd need to use the name of the interface method's named return values (which often aren't named, or are named all lowercase, so the struct field would have unexported fields).

(Braindump from me + @griesemer)

[ianlancetaylor]

Suppose that instead of Pair(F()) we change the rules of composite literals so that a function call with multiple results can be used, and treated as though the results appeared in the composite literal as separate values.

That is, in the original example, instead of

    go func() { c <- Pair(F()) }() 

we permit

    go func( { c <- Pair{F()} }()

This would be permitted for slice/array composite literals as well. (It wouldn't work for maps as there would be no way to specify both the key and the value.)

This seems like a relatively simple extension to the way that functions with multiple results can be used today.

[egonelbre]

Any reason not use:

func NewPair(i int, s string) Pair {
	return Pair{i, s}
}

go func() { c <- NewPair(F()) }()

[griesemer]

@egonelbre Of course this is an option. But I think the point the proposal author is trying to make is that this extra work shouldn't be required: "The goal of this proposal is to allow easy conversion from a function return to a struct with the same field types and order." (#33080 (comment))

[griesemer]

Regarding #33080 (comment), to clarify: Like for function invocations f(g() where g returns multiple results and f accepts multiple results, if S is a composite literal type (struct, array, or slice) we would only allow S{g()} and not S{a, b, g(), c, d} or S{g(), g()}.