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:


  1.
Simplifies head/tail element extraction when pack size is known, avoiding per-element extraction via pack indexing.
  2.
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:


  1.
assignment. No breaking changes to existing code.
  2.
braces. May break some code, but fixes are simple.
  3.
concatenation. May have numerous issues.