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