Do do_return!

Contents

1. Introduction

[P2806R4] proposes a new feature of do expressions, allowing the user to put statements inside of an expression. One notable design aspect is that do expressions permit omitting the do_return statement to produce a result:

In its simplest form:

int x = do { do_return 42; }; int y = do { 42 }; // equivalent to above

A do expression consists of a sequence of statements, but is still, itself, an expression (and thus has a value and a type).

I argue that this is a bad idea, and that do_return should be required, for the reasons listed below.

2. Problems with omitting do_return

2.1. Novelty and inconsistency

The ability to omit keywords like return which would yield results from expressions is a staple of other languages, such as Kotlin and Rust.

The key observation is that in those other languages, the last statement is result design is consistently applied across the language, for a wide variety of constructs. This is not the case in [P2806R4], making that design novel and surprising for do expressions. C++ users have been taught for 30 years that

• blocks enclosed by braces contain a bunch of statements,
• you put a semicolon at the end of the line (unless the line starts with if or whatever), and
• control flow interactions (without which you flow off the end of a block) require a keyword like if, return, break, co_yield, etc.

There is an immense amount of value in these consistent and teachable rules, which [P2806R4] proposes to weaken, for the purpose of reducing verbosity. These rules would no longer be universal rules.

Furthermore, why is the design not applied to other constructs, even though it would be possible in principle?

There are two possible directions here:

• Not changing lambda expressions would be inconsistent with do expressions, without good rationale. We would still sacrifice the consistent and teachable rules by making do expressions special, but we wouldn't get much value in return. Verbosity of lambdas is a common complaint.
• Changing lambda expressions like this retroactively might be fine, but it demonstrates that the last statement is the esult feature is orthogonal to do expressions, and that the design needs to be explored holistically.

Either way, the conclusion seems that [P2806R4] should not be proposing this design. Perhaps it could be done in a separate paper for various constructs in general.

2.2. Competing styles

An inevitable outcome of letting users omit do_return is that there will be competing styles, where some users prefer to always write do_return. This would be motivated by consistency with control flow in other places, like return and co_yield. A C++ developer used to omitting do_return would find it jarring to work on a code base where do_return is always required, and vice versa.

While having some disagreement over style is natural in a programming language, C++ already has a ton of options without a clear winner (initialization style, trailing return types, when to use auto, etc.), and this issue would be compounded. There is real cost to adding more and more competing styles which then either need to be litigated by each code base or lead to inconsistent code within one code base.

2.3. Visually grepping control flow

In the following code block, try to find all the places where control flow is altered in some way:

Toggle blur

Despite this block being blurry and thus completely unreadable, you can actually identify all the if, for, and return statements easily do to their shape and syntax highlighting. The same visual identification of control flow is done subconsciously by developers all the time. Searching for a return statement in a long function doesn't require reading the entire function from top-to-bottom, but rather scanning for the shape and color of a return statement.

As things stand, universally, builtin control flow constructs in C++ can be visually identified in this way. This would not be the case for do_return, which can be omitted.

2.4. Accessibility problems

In the proposed design, there is a major difference between the following expressions:

This design is hostile to users with poor eyesight because a semicolon has major semantic impact. It also shows that having competing styles is not just a matter of preference; one user may prefer to omit do_return because they have 20/20 vision and they optimize for brevity, which is detrimental to other users with poor eyesight.

The design also poorly integrates with screen readers because it requires keeping the screen reader in high verbosity mode to read code. Historically, C++ semicolons could have been largely omitted as noise because they were merely statement terminators, with a few exceptions like for (;;).

2.5. Textually grepping control flow, future direction

Another way to scan for control flow is to perform a text search. If the user is confronted with a long do expression and wants to find all the places where it yields a result, they can search for do_return and jump from search result to search result. This is not possible when the only distinguishing factor between yielding a result and yielding void is a semicolon.

Perhaps initially, the issue is not so bad because the user only has to check the last statement of a do expression to see if it yields a result. However, a logical next step in language design is to allow the following:

This wouldn't be a breaking change because yielding a result of the if expression requires omitting semicolons inside the if statement, which is currently not possible.

Once again, we are confronted with uncomfortable choices:

• If we want to pursue omitting do_return in more places, we should commit to it fully, and consider the consequences for all possible statements rather than just the last statement in a do expression. There is a slippery slope here.
• If we don't want to pursue this, the current design of [P2806R4] is half-baked. If Rust and Kotlin let you omit the do_return equivalent in more places, why can't we? Why would Rust be such an inspiration for the paper if we cherry-pick only a small portion of its syntax and consider the same Rust syntax in other construct to be a bad fit for C++?

2.6. Irregular void and latent bugs

Another observation is that in Kotlin and Rust, the following construct works fine, when it doesn't in C++:

Consequently, the existence of the semicolon becomes hugely significant, especially in templates, where diagnostics are delayed until instantiation.

3. Conclusion

The discussion above shows that there are many serious problems with omitting do_return in do expressions. Consistency with other constructs, teachability, stylistic consistency, accessibility, visual and textual greppability, and other positives aspects of the language are affected where do expressions are used without do_return.

Either, that direction should not be pursued at all, or it should be pursued holistically. That is:

• Do we want to allow omitting the return statement in lambdas, and/or in functions, in general?
• Do we want to allow omitting do_return in the last if and/or try statement of a do expression? What if we want to make if and/or try an expression in the future?
• What other language constructs are affected by this, now and in the future?
• How do these decisions impact overall teachability, greppability, and accessibility of C++?

If we simply ignore these concerns, we risk losing sight of the big picture. This is unjustifiable, especially considering that the omission of do_return can be introduced at any point in the future without breaking changes, since the omitted-semicolon syntax used by the feature is currently ill-formed.

4. References