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_at_[hidden]> 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_at_[hidden]>
> 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_at_[hidden]> 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
>>> <https://gist.github.com/Johan511/3bbae06c683fd343a08aa6c50f1de0ed> that
>>> this won't cause any parsing ambiguities
>>>
>>> --
>>> Hari Hara Naveen
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>
>
> --
> Hari Hara Naveen
>