This setup seems pretty inflexible. Suppose you had

type P struct{x, y int}
var p = P{}
func f(a, b int) {}
f(p...)

That all works fine. But then suppose I want to add a context argument to f?

func f(c *context.Context, a, b int) {}

I'd like to call it like

f(c, p...)

but I understand from this proposal that this wouldn't be allowed. You'd have to do

f(c, p.x, p.y)

I guess that's the same problem when starting with f(g()), but we're adding another instance of the same wart.

More than just having new functionality, I like this proposal because it corrects one of two asymmetries in the language that bother me (the other is #45624): there is special support for assembling a (pointer to a) struct, but none to disassemble one. That is, one can write s := S{a, b} but the existing language provides no shorthand for the reverse operation. This proposal provides one.

#63221 proposes an unpack() builtin that does much the same as ... here and there is a great deal of discussion about that.

This proposal would provide a similar mechanism to tuples that fulfill many of the same goals. However, it would still require creating little types whose only purpose is to temporarily package a group of values together and to name them and their fields. Still, this would be easy to add tuple-structs atop if need be.

How does this work with unexported fields from structs defined in another package: does it skip them or can you just not use ... in that situation?

This feels like a significant downgrade from #63221. It's essentially the exact same as that one but with fewer features, a slightly different syntax, and the added, and nice, ability to pack multiple return values into a non-tuple struct. Of particular note is that this still doesn't solve what I think is most people's main frustration: Needing to create a named type to be able to send multiple things through a channel.

c := make(chan struct{int, string}, 1)
a, b := (<-c)... // Works under this proposal.
c <- struct{int, string}{a, b} // Still just as awkward as it has been.

How does this work with unexported fields from structs defined in another package: does it skip them or can you just not use ... in that situation?

@jimmyfrasche I'd vote for the second option. (that being a compile error)
Same with packing function return value assignments

@randall77 If we can come up with clean and unambiguous rules for adding a parameter to an f in a call f(g()) where g() returns multiple values, it seems like we can apply the same "fix" to this proposal. This seems an orthogonal problem to the proposal that can be addressed independently.

@jimmyfrasche As you say yourself, this proposal doesn't preclude a future mechanism that auto-infers a struct type or perhaps even a tuple from a set of values, if that is important. But that's an independent consideration, and adding a tuple type is a more significant change that seems less warranted. This proposal generalizes mechanisms we already have (... to unpack things, and passing multiple values to functions or a composite literal in this case). So this is a much simpler proposition. It can be seen as a completing/rounding out of existing features rather than the introduction of new concepts.

With respect to unpacking a struct with unexported fields: it's a very good question and I don't know what the right answer is. If we strictly follow existing rules, unpacking would be allowed: exporting simply controls access to names, nothing more. Since we don't mention the names, we're ok. It reminds me of #56669 which is unrelated but exposes a similar problem. Alternatively, one could disallow ... in that specific case. Finally, just ignoring unexported fields seems the worst of the possible choices.

@DeedleFake Agreed that #63221 does more, but this proposal doesn't preclude a future mechanism to auto-infer struct types. It seems orthogonal.

if we add a field to S without changing the signature of f, the code will break.

The same applies if we change the order of fields, which is already true for unkeyed struct literals as well. If this proposal is adopted, the section in the Go 1 Compatibility Promise should be extended with a note that usage of this feature is not covered.

FWIW, my vote is that unpacking across packages with an unexported field is disallowed. I also think unpacking across packages should be flagged by go vet unless the struct has a magic comment like //go:unpackablefields or something. Maybe a magic struct tag, but then you’d have to repeat it for each element.

I don’t suppose this needs any reflect support, but it might be convenient to have.

Overall, I like this because it aligns Go with other languages like Python, JavaScript, etc that have a destructuring operator.

What about unpacking a slice? Maybe e1, e2 := s… and it will panic if s isn’t exactly len 2?

Re: slice unpacking, since you can already convert a slice to an array, it seems like not having slice unpacking would just make people add an extra hoop to jump through.

it aligns Go with other languages like Python, JavaScript, etc that have a destructuring operator

Note that some destructuring operators in other languages are sensitive to the field names. Consider this (typed on my phone, may be typos):

type S struct {
  n int
  off int
}

// …
s := S{n: 9, off: 5}
n, off := s…

If you swap the order of the fields in the type definition of S, you get a confusing bug.

Name-based destructuring isn’t a great fit for Go, because local variables aren’t typically capitalized. And it doesn’t solve the tuple use case.

But position-based destructuring is enough of a footgun that I expect/hope it’d be used sparingly.

Position-based is not robust. It's a fundamental problem with position-based tuple access.
For the de-structuring case, this isn't robust to a change in the struct field ordering as @josharian points out. There may be no compiler error.
For the function call case, it isn't robust to adding or removing a struct field or a function parameter. This would produce a compiler error but require backing out the use of this feature.

I think Typescript and Javascript have this right by using name based de-structuring and structuring (it also supports position-based de-structuring and tuples via arrays with multiple types, but I stay away from those features and in code in the wild they are used much less than name-based).

let o = {
  a: "foo",
  b: 12,
  c: "bar",
};
let { a, b } = o;
let { a, ...passthrough } = o;
let total = passthrough.b + passthrough.c.length;

It also supports name-based object structuring

let defaults = { food: "spicy", price: "$$", ambiance: "noisy" };
let search = { food: "rich", ...defaults };
let a = 1
let b = 2
obj = { a, b}
obj.a // 1

If you thought the language needs to be loosy-goosy, that's not the case: Rust supports this as well- both destructuring and structuring.

A lot of the desire for Tuples in Go comes down to it's choices to have non-tupled multi-valued returns and to not having tagged unions or initially generics, which required these returns almost everywhere.

There's room to perhaps allow something along the lines of this proposal, but there are 2 other related features that get used heavily in other languages that I think should be designed first because there is a lot of potential overlapping use cases where one would currently imagine this proposal being used:

• name-based de-structuring and structuring
• tagged unions

I am generally in favor of this proposal. However, it is not clear to me how this proposal would integrate with the special form of assignment for maps and the special form of receive. For example:

var m map[int]struct{x int, y string}
// ...
a, b, ok := m[2]...

var ch chan struct{x int, y string}
// ...
a, b, ok := <-ch...

If these forms were allowed, changing the struct from struct{x int, y string} to struct{x int, y string, z bool} would still compile, but the behavior would be different.

It might be possible to disallow the use of ... in these special forms, but I think it would be unfortunate. For example, you would have to write:

if d, ok := m[2]; ok {
        a, b = d...
        // do something with a and b
}

instead of

if a, b, ok := m[2]...; ok {
        // do something with a and b
}

#64613 (comment)

I would draw the opposite conclusion that unexported fields can be accessed from another package.

a, b := s2... // unpacking of s2; a = 1, b = 2; shortcut for a, b := s2.x, s2.y

This relatively nice view is that unpacking is shorthand for a sequence of selector expressions of the listed fields of a struct. One cannot write s2.x in another package. It would be a compile error. So to be consistent with this means that unpacking a struct p.S in package q is a compile error if p.S has any unexported fields.

Sticking unpacking being shorthand for a sequence of selectors/array accesses, something that pops out is a *p.S could also be unpacked using this principle.

(I am not sure there is a way to deal with embedded structs or interfaces with unpack other than to select the embedded struct/interface. Otherwise there will be ambiguities for the cardinality of the left hand side. So it would not be all valid selectors on p.S, just ones listed on the struct.)

destructuring may be worth exploring but it wouldn't help with f(s...) or S{g()...}.

It would allow the comma-ok forms to work on one line instead of two without any ambiguity over where the ok came from:

var c chan [2]T
// ...
[x, y], ok := <-c

With respect to unpacking a struct with unexported fields: it's a very good question and I don't know what the right answer is. If we strictly follow existing rules, unpacking would be allowed: exporting simply controls access to names, nothing more. Since we don't mention the names, we're ok. It reminds me of #56669 which is unrelated but exposes a similar problem. Alternatively, one could disallow ... in that specific case. Finally, just ignoring unexported fields seems the worst of the possible choices.

Unpacking unexported fields doesn't seem ideal. That would make it unsafe, but possible, to use with any struct you don't have control over. You don't want a patch update in a third part dependency breaking the build because it made an internal change.

One way to go would be to make it the opposite of an unkeyed literal. If so, then it would make since that s... would be illegal if its type cannot be written as an unkeyed literal in the current package. For the most part that seems like it would work out well. The annoyance would be that for structs defined in the same package it would unpack _ fields which are always zero. (I don't suppose it's possible to make it illegal to use an unkeyed literal with _ fields at this point?)

Another option would be to treat it as a macro that is equivalent to writing out all the fields by hand and thus only including the ones that the user could otherwise write. In the same package, all non-_ fields are expanded; in exterior packages, all exported fields are expanded.

A hybrid option would be to never unpack _ fields and disallow structs from another package that contain non-exported fields to be expanded. That seems like the best thing from a usability point of view even if it's not really consistent.

GLSL has a feature called swizzling, which essentially gives the programmer control over which fields to unpack. Perhaps this can be adapted for Go?

 type Pair struct{a, b int}
 var p Pair
-x, y := p...
+x, y := p.{a,b}
+v, u := p.{b,a} // reverse order
 
+i, j, k, l := p.{a,a,b,b}
+i == j
+k == l
 
 type S2 struct{x, y int}
 s2 := S2{1, 2}
-s2 == S2{s2...}
+s2 == S2{s2.{x,y}}
 func f2(a, b int)
-f2(s2...)
+f2(s2.{x,y})

@myaaaaaaaaa

I don't see how that's particularly better than just doing

x, y := p.a, p.b
v, u := p.b, p.a // reverse order

i, j, k, l := p.a, p.a, p.b, p.b
i == j
k == l

s2 == S2{s2.x, s2.y}

f2(s2.x, s2.y)

It saves a very minor number of keystrokes in return for very little in these examples, in my opinion.

@gazerro If you need the comma-ok form, you need to do the unpacking in two steps:

var m map[int]struct{x int, y string}
v, ok := m[2]
a, b := v...

This is explained in the example section of the proposal.

The argument against unpacking (not robust, what to do about unexported fields, embedded fields) seem pretty convincing: these are valid technical arguments.

Since s... (as nice as it may read) would be just syntactic sugar for s.a, s.b, s.c (or whatever the field names of s are, we probably should avoid that footgun in favor of being explicit. We can already write what s... achieves, it's just a bit longer. Notably, there's no need to introduce temporaries, etc (at least as long as s is not some more complex expression).

This leaves the original idea of #33080: a mechanism to pack a multi-value into a struct (i.e., only 2) of this proposal):

Given a struct or array type T with n elements and an expression e that stands for n values (a multi-value) of matching types, the composite literal T{e} creates the struct or array value with the multiple values as the elements.

This would still allow us to easily pack a multi-value returned by a function into a struct (or an array) without the need to go through temporary variables. Do people see any problems with that?

If unpacking simply corresponds to what is being done manually, doesn't seem to me that it should be too problematic?

• unexported fields wouldn't be unpacked since when inaccessible
• embedded fields would be unpacked in variables as normal, these are just some kind of unnamed fields in a sense

That means that packing and unpacking won't necessarily be symmetric for every struct type but I think that would be ok.
It is for a certain kind of structs. (those exhibiting tuple-like qualities, so to speak)

The advantage is that, although perhaps ugly in user-land, one could address the issue mentionned by @randall77 at the top:

f(pack(c, p...)...)

Just by composition. Where pack represents the operator that packs into a struct.

Then again, if that's something that can be implemented without that operator, not only will it be simpler but also more legible. Perhaps it will still help the underlying implementation. So just a note, just in case.

Edit:
These tuple like structs would only be unpackable within the package the unpacking appears in. (sic!) so it's not too worrying. No asymmetry between packing and unpacking within a package, even in presence of unexported fields.

If unpacking is desired, an unpacking function (or method) can still be written to return the corresponding multi-value. This is more verbose, but it is more future-proof and clearly documented.

type S struct {
    a, b int
}

func (s *S) AsList (a, b int) {
    return s.a, s.b
}

The explicit function also makes explicit how the unpacking works with a pointer to struct vs directly a struct.

Notes:

• instead of unpacking I would instead call that destructuring or transforming a named container into a positional container.
• the use cases for destructuring are quite rare. Types named Pair or XY are obvious, but just trivial, and not that common. If you have more than 3 value in the struct, explicit destructuring is safer (protects against future change in stuct members order change).

The major issue with destructuring is that the Go lacks support for using multi-value in various place. Multi-values basically only work on the right side of an assignment. They also work as arguments to another function, but I never found that useful as I usually have to handle an error.

I have written such destructuring methods a few times when using database/sql because the sql.Stmt.QueryContext and sql.Stmt.ExecContext methods take positional list of values. But usually I could not pass directly the output of the destructuring method because I had to build a bigger list of values with values from other sources. I had to write an SQLArgs []any type with a func (*SQLArgs) Append(...any), and my destructuring methods were returning []any instead of having the raw values in the signature (because we can't pass a multi-value to a variadic argument).

@dolmen Not bad. I think the two can/should coexist.
That changing a struct definition by adding a field ends up in compile failure is not necessarily a bad thing. It can also point out the locations where the implementation should be adjusted. Instead of silently compiling without accounting for the change.

In fact, and alternatively, perhaps that only packed structs should be depackable. (perhaps... Need to think about it).
That might make those kind of anonymous structs closer to tuples.
That could also avoid having to find a general methodology for exported vs unexported fields since depacking would just concern these special structs. And avoid proliferation.

Perhaps that it gets closer to what @jimmyfrasche was proposing?

I seem to remember that one previous proposal wanted these values to be immutable. That could kind of be the case if the fields are unexported.

Many ways to skin the cat probably.

The point is that when dealing with generics*, if some way is found to describe such constructed types in terms of type parameters at some point, we can represent generic functions by having them take those packed type parameters in argument or return positions and also have the ability to depack values of such generic types.

In other words, creating a true equivalence between multiple return values and these depackable structs.

(*) Will probably require composablity so that for a type parameter T defined such that[U (...any), T (U, error)], T is not the representation of a struct that embeds itself a struct type and an error type. It should be considered as destructured, equivalent to (U..., error)
Sometimes, we just want to make sure that a function returns an error value.
We are not there at all yet, just thinking out loud. Maybe that can inspire something.

Reviewing this thread I don't see a mention of when you're allowed to do this. I would assume that you would only be allowed to write pkg.S{f()} if you could write an unkeyed composite literal for pkg.S.