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

[Jordan Rose]

On Oct 20, 2012, at 20:23 , Richard Smith <richard at metafoo.co.uk> wrote:

> 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).

Just to clarify, I had assumed that if the constexpr function is the only visible declaration, it would be used as the runtime implementation as well, as it currently is in C++11. I guess in C++11 you can forward-declare a constexpr function without making it constexpr, though, so it's not backwards-compatible.

Jordan