1 Revision History

Since [P2806R3], implementation, wording, introducing implicit last value, and adding an optional init-hoist to do expressions to address lifetime issues.

Since [P2806R2], wording and referencing a longer discussion on divergence in [P3549R0] (Diverging expressions).

Since [P2806R1], switched syntax from do return to do_return to avoid ambiguity. Added section on lifetime.

Since [P2806R0], some more discussion about implicit last value vs explicit return, reflection, and a grammar fix to the still-incomplete wording.

2 Introduction

C++ is a language built on statements. if is not an expression, loops aren’t expressions, statements aren’t expressions (except maybe in the specific case of expression;).

When a single expression is insufficient, the only solution C++ currently has at its disposal is to invoke a function - where that function can now contain arbitrarily many statements. Since C++11, that function can be expressed more conveniently in the form of an immediately invoked lambda.

However, this approach leaves a lot to be desired. An immediately invoked lambda introduced an extra function scope, which makes control flow much more challenging - it becomes impossible to break or continue out of a loop, and attempting to return from the enclosing function or co_await, co_yield, or co_return from the enclosing coroutine becomes an exercise in cleverness.

You also have to deal with the issue that the difference between initializing a variable using an immediately-invoked lambda and initializing a variable from a lambda only differs in the trailing (), arbitrarily deep into an expression, which are easy to forget. Some people actually use std::invoke in this context, specifically to make it clearer that this lambda is, indeed, intended to be immediately invoked.

This problem surfaces especially brightly in the context of [P2688R4] (Pattern Matching: match Expression), where the current design is built upon a sequence of:

This syntax only allows for a single expression, which means that pattern matching has to figure out how to deal with the situation where the user wants to write more than, well, a single expression. The current design is to allow { statement } to be evaluated as an expression of type void. This is a hack, which is kind of weird (since such a thing is not actually an expression of type void), but also limits the ability for pattern matching to support another kind of useful syntax: => braced-init-list:

There’s no way to make that work, because { starts a statement. So the choice in that paper lacks orthogonality: we have a hack to support multiple expressions (which are very important to support) that is inventing such support on the fly, in a novel way that is very narrow (only supports void), that throws other useful syntax under the bus.

What pattern matching really needs here is a statement-expression syntax. But it’s not just pattern matching that has a strong desire for statement-expressions, this would be a broadly useful facility, so we should have an orthogonal language feature that supports statement-expressions in a way that would allow pattern matching to simplify its grammar to:

Indeed, as of [P2688R5] (Pattern Matching: `match` Expression), the { statement } production is gone and the braced-init-list case is now supported. Pattern matching now relies upon do expressions to support multiple statements.

3 do expressions

Our proposal is the addition of a new kind of expression, called a do expression.

In its simplest form:

A do expression consists of a sequence of statements, but is still, itself, an expression (and thus has a value and a type). There are a lot of interesting rules that we need to discuss about how those statements behave.

3.1 Scope

A do expression does introduce a new block scope - as the braces might suggest. But it does not introduce a new function scope. There is no new stack frame. Which is what allows external control flow to work (see below).

3.2 do_return statement

The new do_return statement has the same form as the return statement we have today: do_return expr-or-braced-init-listopt;. Its behavior corresponds closely to that of return, in unsurprising ways - do_return yields from a do expression in the same way that return returns from a function.

While do_return value; and return value; do look quite close together and mean fairly different things, the leading do we think should be sufficiently clear, and we think it is a good spelling for this statement.

Other alternative spellings we’ve considered:

• do return (in the previous revision of this paper, which has an ambiguity with do ... while loops)
• do_yield (presented to EWG in Issaquah as the initial pre-publication draft of this proposal)
• do yield
• do break (similarly to return, we are breaking out of this expression, but is less likely to conflict since break is less likely to be used than return and also the corresponding break value; is invalid today)
• => (or some other arrow, like <- or <=)

3.3 Implicit Last Value

Let’s take the example motivating case from [P2561R2] (A control flow operator) and compare implicit last expression to explicit return:

auto foo(int i) -> std::expected<int, E>

auto bar(int i) -> std::expected<int, E> {
    int j = do {
        auto r = foo(i);
        if (not r) {
            return std::unexpected(r.error());
        }
        *r // <== NB: no semicolon
    };

    return j * j;
}

auto foo(int i) -> std::expected<int, E>

auto bar(int i) -> std::expected<int, E> {
    int j = do {
        auto r = foo(i);
        if (not r) {
            return std::unexpected(r.error());
        }
        do_return *r;
    };

    return j * j;
}

In the simple cases, implicit last value (on the left) will be shorter than an explicit return (on the right). But implicit last value is more limited. We cannot do early return (by design), which means that a do expression would not be able to return from a loop either. We would have to extend the language to support if expressions, so that at the very least the first example above could be made easier - which would add more complexity to the design.

Which is to say — the do_return statement is still a valuable and necessary addition, given that we do not have if or loop expressions, and we are unlikely to add them.

However, for many common uses of do expressions, we don’t actually need early return, so paying the syntactic cost seems unnecessary. Which is why we’re proposing both.

Note that Rust also allows both (you can label a block expression and then break out of it).

3.4 Type and Value Category

The expression do { do_return 42; } is a prvalue of type int. We deduce the type from all of the (non-discarded) do_return statements, in the same way that auto return type deduction works for functions and lambdas.

An explicit trailing-return-type can be provided to override this:

If no (non-discarded) do_return statement appears in the body of the do expression, or every (non-discarded) do_return statement is of the form do_return;, then the expression is a prvalue of type void.

Falling off the end of a do expression behaves like an implicit do_return; - if this is incompatible with the type of the do expression, the expression is ill-formed. This is the one key difference with functions: this case is not undefined behavior. This will be discussed in more detail later.

This makes the pattern matching cases [P2688R4] work pretty naturally:

x match {
    0 => { cout << "got zero"; };
    1 => { cout << "got one"; };
    _ => { cout << "don't care"; };
}

x match {
    0 => do { cout << "got zero"; };
    1 => do { cout << "got one"; };
    _ => do { cout << "don't care"; };
}

Here, the whole match expression has type void because each arm has type void because none of the do expressions have a do_return statement.

Yes, this requires an extra do for each arm, but it means we have a language that’s much easier to explain because it’s consistent - do { cout << "don't care"; } is a void expression in any context. We don’t have a compound-statement that happens to be a void expression just in this one spot.

auto f(int i) {
    return i match -> std::pair<int, int> {
        0 => {1, 2};          // ill-formed
        _ => std::pair{3, 4}; // ok
    }
}

auto f(int i) {
    return i match -> std::pair<int, int> {
        0 => {1, 2};          // ok
        _ => std::pair{3, 4}; // ok
    }
}

Here, the existing pattern matching cannot support a braced-init-list because { is used for the special void-statement-case. But if we had do expressions, the grammar of pattern matching can use expr-or-braced-init-list in the same way that we already do in many other places in the C++ grammar. This example just works.

3.5 Copy Elision

All the rules for initializing from do expression, and the way the expression that appears in a do_return statement is treated, are the same as what the rules are for return.

Implicit move applies, for variables declared within the body of the do expression. In the following example, r is an unparenthesized id-expression that names an automatic storage variable declared within the statement, so it’s implicitly moved:

std::string s = do {
    std::string r = "hello";
    r += "world";
    do_return r;
};

Note that automatic storage variables declared within the function that the do expression appears, but not declared within the statement-expression itself, are not implicitly moved (since they can be used later).

3.6 Control Flow

In a regular function, there are four ways to escape the function scope:

1. a return statement
2. throwing an exception
3. invoking a [[noreturn]] function, std::abort() and std::unreachable()
4. falling off the end of the function (undefined behavior if the return type is not void)

The same is true for coroutines, except substituting return for co_return (and likewise falling off the end is undefined behavior if there is no return_void() function on the promise type).

For a do expression, we have two different directions where we can escape (in a non-exception, non-[[noreturn]] case): we either yield an expression, or we escape the outer scope. That is, we can also:

1. return from the enclosing function (or co_return from the enclosing coroutine)
2. break or continue from the innermost enclosing loop (if any, ill-formed otherwise)

Additionally, for point (4) while we could simply (for consistency) propagate the same rules for falling-off-the-end as functions, then lambdas (C++11), then coroutines (C++20), we would like to consider not introducing another case for undefined behavior here and enforcing that the user provides more information themselves.

That is, the rule we propose is that the implementation form a control flow graph of the do expression and consider each one of the six escaping kinds described above. All (non-discarded) do_return statements (including the implicit do_return; introduced by falling off the end, if the implementation cannot prove that it does not happen) need to either have the same type (if no trailing-return-type) or be compatible with the provided return type (if provided). Anything else is ill-formed.

Let’s go through some examples.

auto a = do {
    if (cond) {
        do_return 1;
    } else {
        do_return 2;
    }
};

auto b = do {
    if (cond) {
        do_return 1;
    } else {
        do_return 2.0;
    }
};

auto c = do {
    if (cond) {
        do_return 1;
    }

    do_return 2;
};

auto d = do {
    if (cond) {
        do_return 1;
    }
};

int e = (do {
    if (cond) {
        do_return;
    }
}, 1);

int f = do {
    if (cond) {
        do_return 1;
    }

    throw 2;
};

int outer() {
    int g = do {
        if (cond) {
            do_return 1;
        }

        return 3;
    };
}

int h = do {
    if (cond) {
        do_return 1;
    }

    std::abort();
};

enum Color {
    Red,
    Green,
    Blue
};

void func(Color c) {
    std::string_view name = do {
        switch (c) {
        case Red:   do_return "Red"sv;
        case Green: do_return "Green"sv;
        case Blue:  do_return "Blue"sv;
        }
    };
}

void func() {
    for (;;) {
        int j = do {
            if (cond) {
                break;
            }

            for (something) {
                if (cond) {
                    do_return 1;
                }
            }

            do_return 2;
        };
    }
}

To reiterate: the implementation produces a control flow graph of the do expression and considers all yielding statements (including the implicit do_return; on falling off the end, if the implementation considers that to be a possible path) in order to determine correctness of the statement-expression. The kinds of control flow that escape the statement entirely (exceptions, return, break, continue, co_return) do not need to be considered for purposes of consistency of yields (since they do not yield values).

3.6.1 noreturn functions

The language currently has several kinds of escaping control flow that it recognizes. As mentioned, exceptions, return, continue, break, and co_return. And, allegedly, goto.

But there’s one kind of escaping control flow that it does not currently recognize: functions marked [[noreturn]]. A call to std::abort() or std::terminate() or std::unreachable() escapes control flow, for sure, but today this is just an attribute:

Pattern Matching has this same problem - it needs to support arms that might std::terminate() or are std::unreachable(), so that proposal currently is introducing a dedicated syntax to mark an arm as non-returning: !{ std::terminate(); }. Which is… less than ideal.

However, the rule in 9.13.10 Noreturn attribute [dcl.attr.noreturn]/2 is:

That is normative wording which we can rely on. The above do expression can only fall off the end if std::abort returns, which is already undefined behavior. We can avoid introducing any new undefined behavior ourselves as part of this feature.

That is: invoking a function marked [[noreturn]] can be considered an escaping control flow in exactly the same way that return, break, throw, etc., are already.

Note that this violates the so-called Second Ignorability Rule suggested in [P2552R2] (On the ignorability of standard attributes), which is a great reason to ignore that rule.

3.6.2 Always-escaping expressions

Consider:

This is weird, but might end up as a result of template instantiation where maybe other control paths (guarded with an if constexpr) actually had do_return statements in them. So it needs to be allowed.

It does lead to an interesting question: what is decltype(do { return; })? We already define decltype(throw 42) to be void, so would this also be void? It’s kind of an odd choice, and it would be nice if we had a specific type for an escaping expression. While we could come up with the right language facility to allow the conditional operator (?:) and pattern matching to work correctly by ignoring arms that are always-escaping, user-defined code would have no way of differentiating between a real void expression (std::print("Hello {}!", "EWG") is actually an expression of type void) and an artificial one (std::abort() is not really the same thing).

We could instead introduce a new type, std::noreturn_t (as an easier-to-type spelling of ⊥), change decltype(throw e) to be std::noreturn_t (since nobody actually writes this - code search results are exclusively in compiler test suites) and treat the return types of [[noreturn]] functions as std::noreturn_t. Then the type system gains understanding of always-escaping expressions/statements and the rules for pattern matching, the conditional operator, do expressions, and arbitrary user-defined libraries just fall out.

See reflector discussion here and more thorough discussion in [P3549R0] (Diverging expressions).

3.6.3 goto

Using goto in a do expression has some unique problems.

Jumping within a do expression should follow whatever restrictions we already have (see 8.10 Declaration statement [stmt.dcl]). Jumping into a do expression should be completely disallowed (we would call the statement of a do expression a control-flow limited statement).

Jumping out of a do expression is potentially useful though, in the same way that break, continue, and return are:

Breaking out of multiple loops is one of the uses of goto that has no real substitute today. The above example should be fine. But referring to any label that is in scope of the variable we’re initializing needs to be disallowed - since we wouldn’t have actually initialized the variable. We need to ensure that the 8.10 Declaration statement [stmt.dcl] rule is extended to cover this case.

Also, while computed goto is not a standard C++ feature, it would be nice to disallow this example, courtesy of (of course) JF Bastien (in this case, we are referring to a label that is within v’s scope. We’re not jumping to it directly, but the ability to jump to it indirectly is still problematic):

3.6.4 Should falling off the end be undefined behavior?

Consider:

Is this statement ill-formed (because there is a control path that falls off the end of the do expression, as discussed in this section) or should this statement be undefined behavior? The latter would be consistent with functions, lambdas, and coroutines (and not an if-you-squint-enough kind of consistency either, this would be exactly identical).

It would make for a simpler design if we adopted undefined behavior here, but we think it’s a better design to force the user to cover all control paths themselves.

3.7 Lifetime

One important question is: when are local variables declared within a do expression destroyed?

Let’s start with this example:

Each do expression is locking the same mutex, mtx. We believe that it is the overwhelming presumption of C++ that both lock_guards will be destroyed at their nearest } (i.e. this will not deadlock). There really is no other reasonable alternative.

However, consider this example, courtesy of Lauri Vasama in the context of discussing lifetime questions in control flow operator ([P2561R2]). Consider this set of functions, where find_interesting returns some span into the given vector (or returns an unexpected):

With do expressions, it would be tempting to implement a TRY macro similar to Rust’s try! macro. In this case, we could try to do it this way (note that in this case decaying is irrelevant, so we just return everything by value):

This looks reasonable. Sure, get_data() is a temporary vector, but it looks like it persists until the ;. But that’s not what would actually happen. If we expand the macro, and add the explicit return type for clarity, this evaluates as:

The temporary std::vector<int> doesn’t persist through the whole do expression, it gets destroyed too soon — so our __r would be holding a dangling span (in the non-error case). That’s… bad.

So we need some way to “persist” that temporary through the end of the outer expression. And it definitely cannot happen automatically, as just pointed out, so it has to be explicit in some way. We can think of three approaches to doing this:

1. We can annotate the local variable __r somehow, such that any temporaries in its initializer persist through the outer full-expression.
2. We can annotate the do expression with some kind of anti-capture list, as in do [__r=e] { ... }
3. We can allow the do expression itself to carry a sequence of init-statements expressly for this purpose.

Having an annotation on a variable retroactively change its lifetime just doesn’t seem like a great idea. For the other two, the comparison looks like this:

do [__r=expr] -> decltype(auto) {
    if (not __r) {
        return std::unexpected(__r.error());
    }
    *FWD(__r)
}

do (auto&& __r = expr;) -> decltype(auto) {
    if (not __r) {
        return std::unexpected(__r.error());
    }
    *FWD(__r)
}

Both syntaxes would provide declarations whose lifetime extends to the end of the full-expression containing the do expression. Any temporaries in those declarations’ initializers are likewise extended to that full-expression. Which means that in this case, the temporary get_data() will not be inside of a new full-expression (the body of the do expression), it will be in the place where it needs to be. We think this is the right approach to addressing lifetime issues, in a way that likely scales better.

Between these, we prefer the init-hoist approach (so named because it’s kind of the opposite of an init-capture), since only one form of init-statement even makes sense here. The downside is that we would need auto&& semantics here rather than auto semantics which lambda init-capture has. It’s inconsistent, but with very strong motivation for the difference — since lambdas can actually escape but do expressions cannot.

The proposed form works.

3.7.1 What about Pattern Matching?

The primary motivation for having an init-hoist is largely around being able to define macros for expressions in ways that actually work properly and to be able to desugar the control flow operator ([P2561R2]) into a do expression.

But, interestingly enough, pattern matching ([P2688R5]) offers a different way to solve both problems that wouldn’t need such a feature:

do [__r=expr] -> decltype(auto) {
    if (not __r) {
        return std::unexpected(__r.error());
    }
    *FWD(__r)
}

expr match -> decltype(auto) {
    let __r => do -> decltype(auto) {
        if (not __r) {
            return std::unexpected(__r.error());
        }
        *FWD(__r)
    }
}

On the right, expr is obviously evaluated outside of the do expression, and so any temporaries within it obviously last until the end of the full-expression.

The question is: do we need to add an init-hoist feature for do expressions (a feature in no small part motivated by pattern matching) if pattern matching could solve it for us?

We think it’s probably a good hedge to do it anyway. We’ll probably ship do expressions first, so the pattern matching paper can simply remove it.

3.7.2 Conditional Lifetime Extension

An interesting sub-question on lifetimes is what does this do:

r1 is our familiar lifetime extension case - a reference is bound to a temporary. r2 is definitely dangling. The temporary is destroyed and definitely does not last as long as r2. But what about r3, is it more like r1 or r2?

In this case, we see the entire do expression - so unlike the general callable case, it may actually be possible for lifetime extension to work here.

But as we’re thinking about it, let’s make the example slightly more complicated:

If r3 doesn’t dangle (and we do lifetime extension), does r4? Well, presumably. But here we have a form of runtime-conditional lifetime extension. That’s still seemingly doable - we would effectively have an optional<T> __storage that is declared before r4 and then r4 is either a reference into that or whatever we got from lvalue().

But even if we made r4 work, r5 now almost certainly cannot - now we’re definitely not binding a temporary to a reference, this is quite adrift from our usual rules.

Which makes us wonder if there’s really any value in being adventurous here - and instead probably consider that there is no lifetime extension in any of these cases, not in r3, not in r4, and definitely not in r5.

3.8 SFINAE-Friendliness

The only part of a do expression that is in the immediate context of a template substitution is the trailing-return-type (if any). Any alternative choice would require SFINAE on statements, which the language does not currently support and we are not trying to tackle in this paper.

This is consistent with lambdas, where the lambda body is not in the immediate context.

3.9 Grammar Disambiguation

We have to disambiguate between a do expression and a do-while loop.

In an expression-only context, the latter isn’t possible, so we’re fine there.

In a statement context, a do expression is completely pointless - you can just write statements. So we disambiguate in favor of the do-while loop. If somebody really, for some reason, wants to write a do expression statement, they can parenthesize it: (do { do_return 42; });. A statement that begins with a ( has to then be an expression, so we’re now in an expression-only context.

A previous iteration of the paper used do return (with a space), which would lead to an ambiguity in the following in the context of a do expression:

This could have been parsed as a do return statement followed by an infinite loop (that would never be executed because we’ve already returned out of the expression) or as a do-while loop containing a single, unbraced, return statement. If we use the do_return spelling, there’s no such ambiguity, since the above can only be a do ... while loop.

Also because we would unconditionally parse a statement as beginning with do as a do-while loop, code like this would not work:

Such code would also have to be parenthesized to disambiguate, which doesn’t seem like a huge burden on the user.

3.10 Prior Art

GCC has had an extension called statement-expressions for decades, which look very similar to what we’re proposing here:

({
    int y = foo();
    int z;
    if (y > 0) z = y;
    else z = -y;
    z;
})

do {
    int y = foo();
    if (y > 0) {
        do_return y;
    } else {
        do_return -y;
    }
}

The reason we’re not simply proposing to standardize the existing extension is that there are two features we see that are lacking in it that are not easy to add:

1. The ability to specify a return type, which is critical for allowing statement-expressions to be lvalues.
2. The ability to support yielding out of different branches of if, due to the implicit nature of the yield.

For (1), there is simply no obvious place to put the trailing-return-type. For (2), you can’t turn ifs into expressions in any meaningful way. It is fairly straightforward to answer both questions for our proposed form.

With allowing implicit last value, the simple translation from gcc statement-expression to do expression is just a matter of swapping parentheses for a leading do (and dropping the ; on the last statement). We’re just generalizing to make the feature more flexible.

3.11 What About Reflection?

A question that often comes up, for any language feature: if we had reflection and, in particular, code injection: would we need this facility?

The answer is not only yes, but reflection is a good motivating use-case for this facility. Because the language does not have any kind of block expression today, adding support for one would increase the amount of ways that code injection could work.

One example might be, again, the control flow operator proposal in [P2561R2] (A control flow operator). If reflection allows me to write a hygienic macro that does code injection, perhaps we could write a library such that try_(E) would inject an expression that would evaluate in the way that that paper proposes. But in order to do such a thing, we would need to be able to have a block expression to inject. This paper provides such a block expression.

3.12 Where can do expressions appear

gcc’s statement-expressions are not usable in all expression contexts. Trying to use them at namespace-scope, or in a default member initializer, etc, fails:

In such contexts, there is a much smaller difference between a statement-expression and an immediately invoked lambda since you don’t have any other interesting control flow that you can do - the expression either yields a value or the program terminates.

But if we’re going to add a new language feature, it seems better to allow it to be used in all expression contexts - we would just have to say what happens in this case. Especially since if we’re adding a feature to subsume immediately invoked lambdas, it would be preferable to subsume all immediately invoked lambdas, not just some or most.

We can think of a do expression as simply behaving like an immediately invoked lambda in such contexts. Not in the sense of allowing return statements (there’s still no enclosing function to return out of), but the sense that any local variables declared would exist in a function stack. But this is probably more of a compiler implementation detail rather than a language design detail.

In short: do expressions should be usable in any expression context.

3.13 Implementation Experience

This is implemented in clang and can be seen on compiler explorer. This example shows the combination of a do expression with an init-hoist and TRY macro with the correct lifetime semantics.

Here is a more involved example showing a more complicated TRY macro illustrating that clang can still warn on dangling references in the right places.

4 Wording

4.1 Lex / Intro

Add the keyword do_return to the table of keywords in 5.12 Keywords [lex.key]:

Add a note to 6.10.1 Sequential execution [intro.execution]:

4.2 Expressions

Add do-expression to the grammar in 7.5.1 Grammar [expr.prim.grammar]:

Extend the rule for move-eligible expressions in 7.5.5.2 Unqualified names [expr.prim.id.unqual]:

Add a new clause [expr.prim.do] after 7.5.8.5 Nested requirements [expr.prim.req.nested]:

4.3 Statements

Change 8.1 Preamble [stmt.pre] to make the compound-statement of a do-expression transparent to the enclosing statement:

Change 8.3 Expression statement [stmt.expr] to disambiguate a do-expression from a do-while loop:

Change 8.4 Compound statement or block [stmt.block] to allow a compound-statement to end in an expression in the context of a do-expression:

Add to the grammar in 8.8.1 General [stmt.jump.general]:

Change 8.8.2 The break statement [stmt.break] to prohibit its use in do-expressions in confusing places:

Change 8.8.3 The continue statement [stmt.cont] similarly:

Add a new subclause [stmt.do.return] “The do_return statement” after 8.8.5 The co_return statement [stmt.return.coroutine]:

4.4 Feature-Test Macro

Add to 15.12 Predefined macro names [cpp.predefined]:

5 References