[tialaramex]

> (caveat: not formally adopted)

Not only was P2137 "not formally adopted" it was purposefully written so that the committee could say explicitly "No" to these goals. It's in some sense a manifesto for one of the 2022 "C++ successor" languages, Carbon not for C++.

If you want to cite actual goals, you won't get much from WG21, which prefers not to get tied down by having any principles to speak of. Bjarne himself however wrote a book in 1994 "Design & Evolution of C++" which might help you determine some goals.

I don't see constexpr functions in particular as a success. There are too many caveats, it's easy to find C++ programmers who've written what they assume is a constant evaluated expression but it isn't, for one of many reasons their compiler has decided it's runtime evaluated, and the programmer was surprised.

[gpderetta]

The reason the standard doesn't guarantee constant evaluation of constexpr is that it would be hard, because of the as-if rule, to specify it in an good way other than a non-normative comment. Remember that as long as the sequence of side effects is preserved (and even that, concurrency introduce non-determinism), any translation is compliant (even no translation in case of interpretation).

In practice you do get guaranteed evaluation wherever the result is required at compile time (for example as a non-type template parameter or as an array size).

[einpoklum]

Your first point is important, and now that you mention it, I do remember similar names from the Carbon introduction and this paper. I should probably look to D&E for a less presumptive set of goals.

As for constexpr - you only get ambiguity if you assign a constexpr expression/function call to a non-constexpr value. If you use constexpr variables to hold the results of your computation, compile-time evaluation is guaranteed. I don't think it's that confusing.