The lack of nested sb first irked me when using dealing with maps where the value is a pair / tuple.

This would obviously also extends to unpacking nested structs easily.

Example:

struct Address
{
    std::string building;
    std::string pincode;
    std::string country;
};

struct Person
{
    std::string name;
    Address addr;
};

auto [name, (building, pincode, country)] = make_person();

// current alternative
auto [name, addr] = make_person();
auto [building, pincode, country] = std::move(addr); // forces move on building, pincode, country

Godbolt link showcasing copies / moves: https://godbolt.org/z/r6aoTEd3f

The proposal is not just purely to reduce verbosity, but also helps elide moves / copies

I do believe unpacking nested packs (structs / pairs / tuples) would not be uncommon and having an elegant way to do it is definitely be well worth the effort.

On Mon, Sep 21, 2026 at 6:04 PM Jan Schultke <janschultke@googlemail.com> wrote:

Personally, I would find the use of parentheses quirky here, but square brackets don't work because [[ and ]] are meant to be for attributes always.

Maybe if you had some really good motivating examples that show where you need nested structured bindings frequently, I could be convinced, but otherwise from me, it's a big

eh, not worth the trouble, and we can't have nice syntax for it

The example that you have provided seems to use an artificially long name for the bindings rather than e.g. [key, val] in order to make the savings seem more significant. Do you have some real-world examples?

On Mon, 21 Sept 2026 at 14:15, HHN via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Currently structured bindings do not allow for nested bindings.

std::map<Identifier, std::pair<Handle, Context>> map;

// to get a copy of identifier, handle and info
for (const auto &[identifierRef, handleWithContextRef] : map)
{
auto identifier = identifierRef;
auto [handle, context] = handleWithContextRef;
}

// Suggested replacement
for(auto [identifier, (handle, context)]: map)
{
}

All sb-identifiers in the structured-binding-declaration will have the same reference qualifier.

Updated in the C++ grammar

sb-identifier :
...opt identifier attribute-specifier-seqopt
( sb-identifier-list ) // new production rule

sb-identifier-list :
sb-identifier
sb-identifier-list , sb-identifier

structured-binding-declaration :
attribute-specifier-seqopt decl-specifier-seq ref-qualifieropt [ sb-identifier-list ]

I have attached an argument that this won't cause any parsing ambiguities

--
Hari Hara Naveen

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals