Sobrecarga de Constexpr

Question

Relacionado: La función que devuelve el constexpr no se compila

Siento que Constexpr es limitado en utilidad en C ++ 11 debido a la incapacidad de definir dos funciones que de otro modo tendrían la misma firma, pero tienen una ser Constexpr y la otra no Constexpr. En otras palabras, sería muy útil si pudiera tener, por ejemplo, un constructor de std :: String que tome solo argumentos constexpr, y un constructor de std :: string no constexpr para argumentos no constexpr. Otro ejemplo sería una función teóricamente complicada que podría hacerse más eficiente utilizando el estado. No puede hacerlo fácilmente con una función Constexpr, por lo que le queda dos opciones: tener una función Constexpr que sea muy lenta si pasa en argumentos no Constexpr, o se da por cuenta por completo (o escriba dos funciones separadas, pero es posible que no sepa a qué versión llamar).

Mi pregunta, por lo tanto, es esta:

¿Es posible que una implementación de C ++ 11 compatible con estándar permita la sobrecarga de funciones en función de que los argumentos sean Constexpr, o esto requeriría actualizar el estándar? Si no está permitido, ¿no estaba permitido intencionalmente?

---

@Nicolbolas: Digamos que tengo una función que mapea un enum a un std::string. La forma más directa de hacer esto, suponiendo mi enum viene de 0 a n - 1, es crear una variedad de tamaño n lleno del resultado.

Podría crear un static constexpr char const * [] y construir un std::string a devolución (pagar el costo de crear un std::string objeto cada vez que llamo a la función), o puedo crear un static std::string const [] y devuelva el valor que busco, pagando el costo de todo el std::string constructores la primera vez que llamo a la función. Parece que una mejor solución sería crear el std::string en memoria en el momento de la compilación (similar a lo que se hace ahora con char const *), pero la única forma de hacer esto sería alertar al constructor que tiene constexpr argumentos.

Para un ejemplo que no sea un std::string Constructor, creo que es bastante sencillo encontrar un ejemplo en el que, si pudiera ignorar los requisitos de constexpr (y así crear un noconstexpr función), podría crear una función más eficiente. Considere este hilo: Pregunta de Constexpr, ¿por qué estos dos programas diferentes se ejecutan en una cantidad de tiempo tan diferente con G ++?

Si llamo fib con un constexpr Argumento, no puedo superar hacerlo mejor que el compilador que optimiza por completo la llamada de la función. Pero si llamo fib con un noconstexpr argumento, es posible que quiera que llame a mi propia versión que implementa cosas como memoización (que requeriría estado), así que tengo un tiempo de ejecución similar a lo que hubiera sido mi tiempo de compilación si hubiera pasado un constexpr argumento.