Structured Binding Assignments

• Document #: P3817R1
• Date: 2026-10-18
• Project: Programming Language C++
• Audience: EWGI, EWG
• Reply-to:
  • Yehonatan Simian <yonisimian@gmail.com>
  • Ran Regev <regev.ran@gmail.com>

History

R1:

Substantive changes:

• Moved the pack ellipsis to postfix (using expr... instead of using ...expr), so an expansion may use any pattern, including a nested pack such as using arr[Is]...

• Specified left-to-right order for using-marked assignments across all three decomposition kinds

• Tightened the “no standard library” motivation into a concrete real-world example (Fuchsia’s Zircon kernel)

• Reversed the ill-formed specifier rules: const, constexpr, constinit and the storage-class specifiers appertain to the hidden object e and are well-formed with using-marked elements

• Drafted the Wording section, replacing the placeholder: the change is confined to the using-marked element, and the specifier rules need no wording at all

• Split sb-identifier into two named forms, sb-declaring-identifier and sb-assigning-identifier, so the wording can name the kind of element it means

• Duplicate targets are now allowed rather than ill-formed: the ban would not have caught a mistake, and it cannot be enforced

• Documented that an assignment target may share a name with a binding the declaration introduces, and that forbidding it is unnecessary

Editorial changes:

• Added clang implementation and implementation-tracker references

• Restructured the back matter: References is now a bibliography of the cited papers. Runnable examples and implementation links moved into their own section.

• Replaced lvalue with modifiable lvalue where the assignment target is meant

R0:

• Initial version

Abstract

This proposal introduces an extension to C++ structured bindings, allowing assignment to existing variables.

Motivation

Structured bindings (auto [x, y] = foo();) can only declare new variables. Assigning to pre-existing variables requires std::tie from <tuple>. There is no single construct that does both.

This proposal closes that gap, with several advantages over std::tie:

1. Mixed-mode — Neither std::tie nor structured bindings alone allow some elements to be new variables and others pre-existing in the same statement. P3817 uniquely enables this:

   int id;
   auto [using id, name] = get_record();  // id is assigned; name is declared

_{[‡ 1]}

2. Unified syntax — One construct for both assignment and initialization reduces cognitive overhead and produces more consistent code. Currently, initialization uses structured bindings; reassignment uses std::tie.

3. Standard library use may be restricted, even where available — Some C++ environments prohibit standard library use by policy, regardless of whether <tuple> is technically present.
   std::tie is unusable there; a language-level feature is usable.

   For example, Fuchsia’s Zircon kernel disallows standard library use in-kernel [CxxInZircon].
   [PageFault] assigns a loop-scoped variable from a structured binding to an out-of-loop variable today:

   auto [fault_status, _] =
       mapping->PageFaultLocked(guest_paddr, pf_flags, 0, &page_request);
   status = fault_status;

   With P3817, this becomes one statement:

   auto [using status, _] =
       mapping->PageFaultLocked(guest_paddr, pf_flags, 0, &page_request);

_{[‡ 2]}

4. Encouraged by [P0144R2] — The authors of the original structured bindings paper explicitly invited this extension [section 3.3]:

   “This can always be proposed separately later as a pure extension if desired.”

Proposal

Extend structured binding syntax to allow the using keyword before an element in the sb-identifier-list to denote assignment to an already-existing modifiable lvalue, rather than declaration of a new variable.

Syntax

The grammar splits sb-identifier into two named alternatives, so that the wording can name the kind of element it means:

sb-identifier:
    sb-declaring-identifier
    sb-assigning-identifier

sb-declaring-identifier:
    ...opt identifier attribute-specifier-seqopt

sb-assigning-identifier:
    using unary-expression ...opt

The sb-declaring-identifier is the existing declaration form, unchanged. The sb-assigning-identifier is new: using followed by a unary-expression that shall designate a modifiable lvalue, optionally followed by .... No attribute-specifier-seq appears in this form: attributes appertain to a newly declared variable, and no variable is introduced here.

Semantics

operator= The hidden variable e is introduced exactly as today (per [dcl.struct.bind] ¶1). The difference lies in how each element SBᵢ is resolved: for a using-marked element, instead of introducing a new name, the implementation assigns from the corresponding element of e to the existing variable via operator=.

Order of assignment. For all three decomposition kinds (tuple-like, array, and otherwise/aggregate), the elements SB₀, …, SBₙ₋₁ are resolved in that lexical order: SBᵢ — its assignment if using-marked, its reference-binding otherwise — is fully completed before SBᵢ₊₁ is evaluated. In particular, for a using-marked SBᵢ, the assignment reads its right-hand element from e and writes it via operator= before any later SBⱼ (j > i) is evaluated.

Rationale: tuple-like decomposition already has this ordering “for free” from [dcl.struct.bind] ¶7, since each SBᵢ there is a separately-initialized variable, sequenced by ordinary declaration semantics. Array and aggregate decomposition never needed an order, since without using every SBᵢ is a side-effect-free reference binding. using adds operator= side effects, making the order observable: auto& [_, using arr[0], using arr[1]] = arr; intends an evict-and-shift, but silently corrupts arr under the other order. This rule generalizes the existing tuple-like guarantee to the two forms that previously had none.

The ref-qualifier determines the type of e, which in turn determines whether the assignment is a copy or a move — no special-casing is required:

auto [using x, y] = f()

auto& [using x, y] = f()

auto&& [using x, y] = f()

Illustration

The expansions below are illustrative — they show the intended semantics in terms of equivalent code, not normative wording. Types shared across all examples:

struct Point { int x, y; };
using PointPair = std::pair<Point, Point>;
PointPair  get_pair();
Point      get_point();

Point arr[2];
Point x;
auto [using x, y] = arr;

Point __e_p3817[2] = {arr[0], arr[1]};
x = std::move(__e_p3817[0]);
Point& y = __e_p3817[1];

Point arr[2];
Point x;
auto& [using x, y] = arr;

Point (&__e_p3817)[2] = arr;
x = __e_p3817[0];
Point& y = __e_p3817[1];

Point arr[2];
Point x;
auto&& [using x, y] = arr;

Point (&__e_p3817)[2] = arr;
x = __e_p3817[0];
Point& y = __e_p3817[1];

Point x;
auto [using x, y] = get_pair();

PointPair __e_p3817 = get_pair();
x = std::get<0>(static_cast<PointPair&&>(__e_p3817));
Point&& y = std::get<1>(static_cast<PointPair&&>(__e_p3817));

PointPair p;
Point x;
auto& [using x, y] = p;

PointPair& __e_p3817 = p;
x = std::get<0>(__e_p3817);
Point& y = std::get<1>(__e_p3817);

PointPair p;
Point x;
auto&& [using x, y] = p;

PointPair& __e_p3817 = p;
x = std::get<0>(__e_p3817);
Point& y = std::get<1>(__e_p3817);

Point x;
auto&& [using x, y] = get_pair();

PointPair&& __e_p3817 = get_pair();
x = std::get<0>(static_cast<PointPair&&>(__e_p3817));
Point&& y = std::get<1>(static_cast<PointPair&&>(__e_p3817));

int px;
auto [using px, y] = get_point();

Point __e_p3817 = get_point();
px = std::move(__e_p3817.x);
int& y = __e_p3817.y;

Point pt;
int px;
auto& [using px, y] = pt;

Point& __e_p3817 = pt;
px = __e_p3817.x;
int& y = __e_p3817.y;

Point pt;
int px;
auto&& [using px, y] = pt;

Point& __e_p3817 = pt;
px = __e_p3817.x;
int& y = __e_p3817.y;

int px;
auto&& [using px, y] = get_point();

Point&& __e_p3817 = get_point();
px = std::move(__e_p3817.x);
int& y = __e_p3817.y;

^† [dcl.struct.bind] ¶8 imposes no aggregate requirement: any class type with publicly accessible direct members and no std::tuple_size specialization reaches this case, including non-aggregates with user-provided constructors.

Immediate-move implication. For auto [using x, ...], the move assignment to x happens at the binding statement, consuming that element of e. A non-using element does not move — it binds a reference into e — so moving out of one always takes an explicit std::move. Where the assignment copies rather than moves, nothing is consumed.

Specifiers

Specifiers appertain to the hidden object e, never to the using-marked targets. [dcl.struct.bind] ¶1 defines S as the declaration’s constexpr, constinit and storage-class specifiers, and e is defined using S together with the declaration’s cv-qualifiers. A using-marked element introduces no new entity — it assigns from the corresponding element of e to an existing variable, whose type this declaration cannot change. Every specifier therefore keeps the meaning it has for an ordinary structured binding, and none of them is ill-formed:

• const qualifies e, and constexpr — valid on structured binding declarations since C++26, [P2686R5] — implies it. The elements read from e are const, so the assignment to a using-marked target copies rather than moves.
• static and thread_local give e static or thread storage duration. e is initialized once; every later execution of the statement assigns from that same e — which earlier iterations may have moved from.
• constinit constrains the initialization of e, and volatile qualifies it. Neither changes what a using-marked element does.

Further Design Decisions

Returned Modifiable Lvalues

The using keyword may also appear before an expression yielding a modifiable lvalue, not just a plain identifier. This is the language-level equivalent of std::tie with non-variable arguments:

// std::tie equivalent
std::tie(foo(), s[0]) = get_pair();

// with P3817
auto [using foo(), using s[0]] = get_pair();

_{[‡ 17]}

C++26 _ Placeholder

P3817 composes naturally with C++26’s _ placeholder for discarding elements:

int x;
auto [using x, _] = get_pair();  // assign first element to x, discard second

_{[‡ 18]}

Note: using _ is ill-formed — _ is a discard placeholder and cannot be the target of an assignment, even where _ names an ordinary variable rather than a placeholder.

This provides a complete, library-free replacement for std::tie with std::ignore:

std::tie(x, std::ignore) = get_pair();

auto [using x, _] = get_pair();

std::tie(std::ignore, y) = get_pair();

auto [_, using y] = get_pair();

Duplicate Targets

A binding list may assign to the same object more than once. The order rule makes the result well-defined — the last assignment wins.

A rule forbidding it was considered and dropped: assigning twice is not a mistake, only pointless, and no test can enforce it — a test on the spelling misses two names for one object, and a test on the objects themselves is undecidable, since using f(), using g() may return the same object:

int var;
int& x = var;
int& y = var;
auto [using x, using y] = foo();  // x and y designate the same object

Reusing a Declared Name as a Target

An assignment target may share its name with a binding the declaration introduces. The operand finds whatever the name means outside the list, since the bindings are not in scope inside it:

struct Counter {
    int count = 0;                                  // the member

    std::pair<int, int> tick();                     // {delta, running_total}

    int step() {
        auto [count, using count] = tick();
        //    │             │
        //    │             └── this `count` is the MEMBER: at this point the
        //    │                 binding declared to its left is not yet in scope
        //    └── declares a local binding named `count`

        use(count);          // the binding — first element (delta)
        return this->count;  // the member  — second element (running_total)
    }
};

The two cases that would warrant a rule are already ill-formed: redeclaring a name that exists in the same scope, and naming a binding that is not yet in scope — which is simply an undeclared identifier. What is left is the deliberate reuse above, whose meaning follows from the ordinary scope rules and whose behaviour is well-defined, so forbidding it is unnecessary.

Packs

P3817 composes naturally with C++26 structured binding packs [P1061R10].

The two forms of sb-identifier place the ellipsis differently on purpose: the sb-declaring-identifier declares a pack, the sb-assigning-identifier expands an existing one. C++ spells a declared pack’s ellipsis on either side of the name (Ts... args, T ...args, ...rest), but spells every pack expansion after its pattern (f(args...)); each form follows the convention of the operation it performs. The two never compete for the same token, since in the assigning form the ellipsis follows an expression.

Non-pack using alongside a regular pack requires no special treatment — the two are orthogonal:

int x;
auto [using x, ...rest]  = get_tuple();  // x is assigned; rest is a new binding pack
auto [...rest, using x]  = get_tuple();  // rest is a new binding pack; x is assigned last

_{[‡ 21]}

using expr... — when ... follows the unary-expression, the sb-identifier is a pack expansion ([temp.variadic]) whose pattern is that expression. Each element of the structured binding is assigned from the corresponding element of e to the corresponding element of the expansion, following the same ref-qualifier rules as non-pack using. No new name is introduced:

template <typename... Ts>
void assign_from(std::tuple<Ts...> t, Ts&... targets) {
    auto [using targets...] = std::move(t);  // each tuple element moved into the corresponding target
}

_{[‡ 22]}

Mixed usage is also valid:

template <typename T, typename... Rest>
void assign_all(T& head, Rest&... tail, std::tuple<T, Rest...> t) {
    auto [using head, using tail...] = std::move(t);
}

_{[‡ 23]}

The operand may be any expression, not only a name. The unexpanded pack may appear anywhere within the pattern — as the pattern itself (targets) or nested inside it (arr[Is]) — exactly as in any other pack expansion:

template <typename... Ts, std::size_t... Is>
void assign_into(std::tuple<Ts...> t, std::array<std::common_type_t<Ts...>, sizeof...(Is)>& arr,
                 std::index_sequence<Is...>) {
    auto [using arr[Is]...] = std::move(t);  // each tuple element moved into the corresponding arr[Is]
}

_{[‡ 24]}

More than one expansion is allowed — any number of using expansions may appear in one binding list, and a declaring pack may appear alongside them. Nothing is left to infer: each expansion’s length is fixed by the pack named in its pattern, so only a declaring pack’s size comes out as the remainder, and the C++26 rule that a declaration contains at most one declaring pack ([P1061R10]) is what keeps that remainder well-defined.

auto [using a..., using b...] = get_tuple();  // |a| + |b| must be the number of elements of the tuple

The existing constraints extend naturally:

• using _... is ill-formed — _ is a discard placeholder.
• Taken together, the pack expansions must produce exactly the structured binding size of E less the number of non-pack elements; otherwise the program is ill-formed.

Current Alternatives

Assigning from a tuple-like type to a pack of existing variables without P3817 requires either the standard library or significant boilerplate:

template <typename... Ts>
void assign_from(std::tuple<Ts...> t, Ts&... targets) {
    // Option 1: std::tie — requires <tuple>
    std::tie(targets...) = std::move(t);

    // Option 2: index sequence — verbose
    [&]<std::size_t... Is>(std::index_sequence<Is...>) {
        int dummy[] = { (targets = std::get<Is>(std::move(t)), 0)... };
        (void)dummy;
    }(std::index_sequence_for<Ts...>{});
}

With P3817:

template <typename... Ts>
void assign_from(std::tuple<Ts...> t, Ts&... targets) {
    auto [using targets...] = std::move(t);
}

_{[‡ 25]}

Examples

Patterns

Loops

Because the structured binding declaration fires on every iteration, using-marked elements are reassigned each time. This enables tracking state across iterations without a separate assignment in the loop body:

// Returns {head, tail} split at the first delimiter
std::pair<std::string_view, std::string_view>
split_first(std::string_view s, char delim);

std::string_view remaining = input;
while (!remaining.empty()) {
    auto [token, using remaining] = split_first(remaining, ' ');
    process(token);
}

_{[‡ 26]}

Mixed-mode is equally natural — accumulate one variable while binding fresh names for the rest:

struct Point { double x, y; };
std::vector<std::pair<Point, double>> trajectory;  // {position, timestamp}

Point last{};
for (auto [using last, _] : trajectory) { /* last updated each step */ }
// last is the final point of the trajectory

_{[‡ 27]}

Real-World Examples

1. llvm PassBuilder

Expected<bool> PassBuilder::parseSinglePassOption(StringRef Params,
                                                  StringRef OptionName,
                                                  StringRef PassName) {
  bool Result = false;
  while (!Params.empty()) {
-    StringRef ParamName;
-    std::tie(ParamName, Params) = Params.split(';');
+    auto [ParamName, using Params] = Params.split(';');

    if (ParamName == OptionName) {
      Result = true;
    } else {
      return make_error<StringError>(
          formatv("invalid {} pass parameter '{}'", PassName, ParamName).str(),
          inconvertibleErrorCode());
    }
  }
  return Result;
}

2. scylladb: repair/row_level.cc

- mutation_reader rd(nullptr);
- std::tie(rd, _reader_handle) = make_manually_paused_evictable_reader(
+ auto [rd, using _reader_handle] = make_manually_paused_evictable_reader(
    std::move(ms),
    _schema,
    _permit,
    _range,
    _schema->full_slice(),
    {},
    mutation_reader::forwarding::no);

3. tools/scylla-nodetool.cc

- std::tie(params["kn"], params["cf"]) = *split_kt(kn_msg);
+ auto [using params["kn"], using params["cf"]] = *split_kt(kn_msg);

Alternative Syntaxes Considered

Option A: & Symbol

int x;
auto [&x, y] = get_values();

Pros:

• Concise
• & suggests “referencing something that already exists”
• Familiar to developers comfortable with reference syntax

Cons:

• Ambiguous with address-of in expressions like auto [&get_reference(), y] = ...
• ]] in auto [&map[key], y] resembles attribute syntax
• Visual similarity to auto& [x, y] may cause initial confusion

Option B: using Keyword (preferred by authors)

int x;
auto [using x, y] = get_values();

_{[‡ 28]}

Pros:

• Unambiguous — no confusion with address-of or function pointers
• Clear semantic intent: “using” an existing variable rather than declaring a new one
• Works cleanly with returned modifiable lvalues: auto [using get_reference(), y] = ...
• Echoes the existing use of using to refer to a name declared elsewhere.

Cons:

• More verbose than &
• Introduces contextual keyword usage within structured bindings

Other Syntaxes (Rejected)

• =x — Conflicts with lambda capture-by-value intuition ([=]).
• let — Conflicts with Pattern Matching proposals.
• tie x — Overly verbose; confusingly evokes std::tie even though it does not use it.
• Implicit (no specifier) — Would silently assign or shadow based on scope, violating the principle of least surprise.

Wording

The wording below is relative to [N5054]. Changes are marked as insertions and deletions. Paragraph numbers are those of [N5054]; an inserted paragraph shifts the numbering of the paragraphs that follow it, and no renumbering is shown.

Preamble: [dcl.pre]

Replace the production for sb-identifier:

sb-identifier:
    sb-declaring-identifier
    sb-assigning-identifier

sb-declaring-identifier:
    ...opt identifier attribute-specifier-seqopt

sb-assigning-identifier:
    using unary-expression ...opt

Structured binding declarations: [dcl.struct.bind]

[1]

• “A structured binding declaration introduces the identifiers v₀, v₁, v₂, …, v_N−1 of the sb-identifier-list of the sb-declaring-identifiers in its sb-identifier-list as names.”
• An sb-declaring-identifier whose identifier is preceded by an ellipsis, or an sb-assigning-identifier whose unary-expression is followed by an ellipsis, is a pack sb-identifier; the elements of a pack sb-identifier are the elements of the structured binding pack it introduces, or of the pack expansion it expands, as applicable.
• “An sb-identifier that contains an ellipsis An sb-declaring-identifier whose identifier is preceded by an ellipsis introduces a structured binding pack.”
• “A structured binding is either an sb-declaring-identifier an sb-identifier that does not contain an ellipsis whose identifier is not preceded by an ellipsis or an element of a structured binding pack.”
• “The optional attribute-specifier-seq of an sb-identifier an sb-declaring-identifier appertains to the associated structured bindings.”
• “The type of the id-expression e is called E. [Note 1: E is never a reference type ([expr.prop]). — end note] The id-expression e is an lvalue if the type of the entity e is an lvalue reference and an xvalue otherwise.”

[2]

• “The structured binding size of E, as defined below, is the number of structured bindings elements that need to be introduced resolved by the structured binding declaration.”
• “If there is no structured binding pack pack sb-identifier, then the number of elements in the sb-identifier-list shall be equal to the structured binding size of E.”
• “the number of elements of the structured binding pack of the pack sb-identifiers is shall be equal to the structured binding size of E less the number of non-pack elements in the sb-identifier-list.”

[3]

• “Let SBᵢ denote the i^th structured binding element in the structured binding declaration after expanding the structured binding pack pack sb-identifiers, if any.”
• [Note 2: If there is no structured binding pack, then SBᵢ denotes vᵢ. — end note]

Insert after ¶3:

An sb-assigning-identifier introduces no names and is not a structured binding. If it is not a pack sb-identifier, the object designated by its unary-expression is its assignment target, and that unary-expression shall be a modifiable lvalue. If it is a pack sb-identifier, the pattern designates one assignment target per element of the expansion, and each of them shall be a modifiable lvalue.

For each SBᵢ that is not a structured binding, the assignment expression target = element is evaluated, where target is the assignment target of SBᵢ and element is the object or value that corresponds to SBᵢ — the element i of the array in the array case, the initializer in the tuple-like case, or e.mᵢ in the member case.

An SBᵢ that is a structured binding is resolved by introducing it; any other SBᵢ is resolved by evaluating its assignment expression. The initialization of e, and any conversion of e considered as a decision variable ([stmt.pre]), is sequenced before the resolution of SB₀, and the resolution of SBᵢ is sequenced before the resolution of SBᵢ₊₁.

Insert after ¶5:

If the unary-expression of an sb-assigning-identifier is the identifier _, the program is ill-formed.

[6], [7], [8]

• ¶6: “Each SBᵢ that is a structured binding is the name of an lvalue that refers to the element i of the array and whose type is T; the referenced type is T.”
• ¶7: “In either case, e is an lvalue if the type of the entity e is an lvalue reference and an xvalue otherwise.” (moved to ¶1)
• ¶7: “variables are introduced with unique names rᵢ as follows for each SBᵢ that is a structured binding, a variable is introduced with a unique name rᵢ as follows” — before S Uᵢ rᵢ = initializer ; — and “Each SBᵢ that is a structured binding is the name of an lvalue of type Tᵢ that refers to the object bound to rᵢ; the referenced type is Tᵢ.”
• ¶7: “The initialization of e and any conversion of e considered as a decision variable ([stmt.pre]) is sequenced before the initialization of any rᵢ.” “The initialization of each rᵢ is sequenced before the initialization of any rⱼ where i<j.”
• ¶8: “each SBᵢ that is a structured binding is the name of an lvalue that refers to the member mᵢ of e and whose type is that of e.mᵢ; …”

Variadic templates: [temp.variadic]

In ¶4, restrict the definition to the declaring form:

• “A structured binding pack is an sb-identifier an sb-declaring-identifier that introduces zero or more structured bindings ([dcl.struct.bind]).”

In ¶6, add to the list of contexts in which a pack expansion can occur:

• (6.19) — In an sb-assigning-identifier ([dcl.struct.bind]); the pattern is the unary-expression.

Implementation

The examples in this paper run against a clang implementation of P3817. A snippet that is cross-referenced as [‡ N] links to the numbered row below; every row points to a runnable Godbolt page, in the order the paper presents them.

Implementation and ongoing work:

• clang implementation — llvm-project-fork, branch p3817
• Issues tracker for active work on P3817

References

• [N5054] Thomas Köppe. Working Draft, Programming Languages — C++.
  https://wg21.link/N5054
• [P0144R2] Herb Sutter, Bjarne Stroustrup, Gabriel Dos Reis. Structured Bindings.
  https://wg21.link/P0144R2
• [P1061R10] Barry Revzin, Jonathan Wakely. Structured Bindings can introduce a Pack.
  https://wg21.link/P1061R10
• [P2686R5] Corentin Jabot, Brian Bi. constexpr structured bindings and references to constexpr variables.
  https://wg21.link/P2686R5
• [CxxInZircon] The Fuchsia Project. C++ in Zircon — “No std in kernel”.
  https://fuchsia.googlesource.com/fuchsia/+/HEAD/docs/development/languages/c-cpp/cxx.md#no-in-kernel
• [PageFault] The Fuchsia Project. Zircon source — zircon/kernel/hypervisor/aspace.cc.
  https://fuchsia.googlesource.com/fuchsia/+/6a563ae1d358f78987bc0c67868bd5ab0a1e39cb/zircon/kernel/hypervisor/aspace.cc#L128