On Tue, 1 Apr 2025 at 14:46, Yexuan Xiao via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> P1061 introduced packs in structured binding declarations, an excellent improvement that allows tuple-like types to be converted into packs while bundling remaining elements.
>
> auto [x, ...rest, z] = std::tuple<int,int,int>{0,1,2};
> auto t = std::forward_as_tuple(rest...);
>
> However, pack expansions cannot directly initialize structured bindings:
>
> auto [x, ...rest, z] = args...; // currently unsupported and always ill-formed
>
> Although P2662 Pack Indexing enables positional access to pack elements, extracting an unknown number of elements into a new pack still requires metaprogramming.
>
> This proposal suggests standardizing `auto [x, ...rest, z] = args...;` to enable pack expansion in structured binding initializations, providing two key benefits:
>
> Simplifies head/tail element extraction when pack size is known, avoiding per-element extraction via pack indexing.
> Enables sub-pack extraction from existing packs, replacing metaprogramming with cleaner syntax (potentially improving compilation speed).
>
>
> auto [x, ...rest, z] = args...;
> // same as
> auto [x, ...rest, z] = std::forward_as_tuple(std::forward<decltype(args)>(args)...);
>
> Alternative syntax candidates:
>
> auto [x, ...rest, z]{args...};
>
> This syntax introduces breaking changes when `sizeof...(args)` equals 1:
>
> auto [x, y]{args...}; // well-formed only if sizeof...(args) == 1
> // and args...[0] is tuple-like
>
> Current standard make such declarations ill-formed for non-unary packs.
>
> Existing code patterns like:
>
> if constexpr(sizeof...(args) == 1) {
> auto [x, y]{args...};
> }
>
> would require migration to:
>
> if constexpr(sizeof...(args) == 1) {
> auto [x, y] = args...[0];
> }
>
> for this proposal.
>
> Additional considerations: pack concatenation
>
> auto [...rest0] = args0..., x; // #1 (currently ill-formed)
> auto [...rest1] = args0..., args1...; // #2 (currently ill-formed)
> auto [...rest2] = x, y; // #3 (potential breaking change)
> auto [...rest3]{x, y}; // #4 (currently ill-formed)
>
> Case #3 becomes breaking if `x` overloads the comma operator to return a tuple-like type.
>
> This proposal consists of three tiers:
>
> assignment. No breaking changes to existing code.
> braces. May break some code, but fixes are simple.
> concatenation. May have numerous issues.


I would expect that if I can do

auto [x, y] = pack...;
and pack expands to
foo, bar
I can then also do
auto [x, y] = foo, bar;

We could technically do that, and state that that's not a comma-expression.

But the question, before going into that is this. WHY?
I can already do
auto x = foo;
auto y = bar;

Yeah sure you can't do
auto [...pack] = another_pack...;

Why would I need to? I can index into the pack, or just use the pack as it is.