Maybe a better syntax for it would be to inspire from designated
initializers, with the dot-prefix.

Like so:
ˋˋˋcpp
std::map<std::pair<int, std::string>, std::tuple<bool, float, char>>
horrible_map { make_nightmare_map() };

for (auto& [ .[id, name], .[isFoo, price, symbol] ]: horrible_map) {
    // ...
}
ˋˋˋ

I believe this would disembiguate syntaxe from attributes as ˋ[[ˋ is not a
valid structured binding opening syntax.
For uniformity I also would allow (but not force) having a do even when not
introducing a sub-binding:

ˋˋˋcpp
auto [.id, .name] = get_my_pair();
ˋˋˋ

Le lun. 21 sept. 2026, 15:29, Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> a écrit :

> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>