title: constexpr overloading
body: <p>Related: <a href="https://stackoverflow.com/questions/7779013/probrem-with-constexpr-how-to-resolve-it">Function returning constexpr does not compile</a></p>
  
  <p>I feel like constexpr is limited in usefulness in C++11 because of the inability to define two functions that would otherwise have the same signature, but have one be constexpr and the other not constexpr. In other words, it would be very helpful if I could have, for example, a constexpr std::string constructor that takes constexpr arguments only, and a non-constexpr std::string constructor for non-constexpr arguments. Another example would be a theoretically complicated function that could be made more efficient by using state. You can't easily do that with a constexpr function, so you are left with two choices: have a constexpr function that is very slow if you pass in non-constexpr arguments, or give up on constexpr entirely (or write two separate functions, but you may not know which version to call).</p>
  
  <p>My question, therefore, is this:</p>
  
  <p>Is it possible for a standard-compliant C++11 implementation to allow function overloading based on the arguments being constexpr, or would this require updating the standard? If it is not allowed, was it intentionally not allowed?</p>
  
  <hr>
  
  <p>@NicolBolas: Say I have a function that maps an <code>enum</code> to a <code>std::string</code>. The most straight-forward way to do this, assuming my <code>enum</code> goes from <code>0</code> to <code>n - 1</code>, is to create an array of size <code>n</code> filled with the result.</p>
  
  <p>I could create a <code>static constexpr char const * []</code> and construct a <code>std::string</code> on return (paying the cost of creating a <code>std::string</code> object every time I call the function), or I can create a <code>static std::string const []</code> and return the value I look up, paying the cost of all of the <code>std::string</code> constructors the first time I call the function. It seems like a better solution would be to create the <code>std::string</code> in memory at compile time (similar to what is done now with <code>char const *</code>), but the only way to do this would be to alert the constructor that it has <code>constexpr</code> arguments.</p>
  
  <p>For a an example other than a <code>std::string</code> constructor, I think it's pretty straight-forward to find an example where, if you could ignore the requirements of <code>constexpr</code> (and thus create a non-<code>constexpr</code> function), you could create a more efficient function. Consider this thread: <a href="https://stackoverflow.com/questions/7065200/constexpr-question-why-do-these-two-different-programs-run-in-such-a-different">constexpr question, why do these two different programs run in such a different amount of time with g++?</a></p>
  
  <p>If I call <code>fib</code> with a <code>constexpr</code> argument, I can't beat do better than the compiler optimizing away the function call entirely. But if I call <code>fib</code> with a non-<code>constexpr</code> argument, I may want to have it call my own version that implements things like memoization (which would require state) so I get run time similar to what would have been my compile time had I passed a <code>constexpr</code> argument.</p>