[cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions

[Richard Smith]

On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis
<gdr at integrable-solutions.net> wrote:
> On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> While throwing things out there, why not just optionally allow constexpr functions to coexist with non-constexpr functions of the same name, like inline and non-inline?

I think this is fundamentally the wrong approach. Constexpr functions
aren't a different kind of function, they're just functions for which
are sometimes required to be evaluated at translation time. Hence
overload resolution should not depend on whether a function is
constexpr. Also, this approach tends to require two definitions of
constexpr functions even where the definitions are the same (if one
calls a constexpr overload and the other calls a non-constexpr
overload). What we want is just a mechanism to make function
invocation substitution take a different path if it encounters a
function which it can't process (because the runtime form of that
function is somehow written in a way that it can't handle).

> Or remove most of the restrictions on constexpr functions that were necessary
> only to win approval for C++11.  This case doesn't strike me as one of
> those where you fight complexity with even greater complexity.
>
> Allow loops and the like in constexpr functions and be done with it.  See my
> comments on the C++ Extension Working Group when these (and related)
> issues where brought up.

Yes, I completely agree, but I don't think this solves the whole
problem. There are certain constructs which we are unlikely to *ever*
permit in constexpr functions, such as (as an extreme case) inline
assembly. Where possible, we should share an implementation between
compile time and runtime. This proposal is for the exceptional cases
(which, over time, should become fewer and fewer), and as a stopgap
measure while we work towards the right solution.