Thanks for providing a more concrete example.

However, this is presenting a false dichotomy. You could also use addr.building and addr.country in subsequent code; you don't have to std::move out of the bindings. If you only needed name and country, it would be tedious to destructure everything, so it's a case-by-case thing whether the nested destructuring is helpful or harmful.

Without a more complete example, it's not possible to make a judgment here.

The issue of std::pair and std::tuple can also be solved by making a simple aggregate with proper names. I personally consider std::pair "never use" and std::tuple "only use for variadics". If you avoid these, you don't end up bullying yourself into structured bindings as the result of .first and .second being bad names.

On Mon, 21 Sept 2026 at 15:24, HHN <harihara.sn@gmail.com> wrote:

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

--
Hari Hara Naveen