Date: Mon, 21 Sep 2026 18:53:51 +0530
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
>>
>
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
Received on 2026-09-21 13:24:06
