On Oct 20, 2012, at 20:23 , Richard Smith <rich...@metafoo.co.uk> wrote:
> On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis > <g...@integrable-solutions.net> wrote: >> On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose <jordan_r...@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
