I'm not sure this is really necessary. gcc and Apple's clang optimize the factorial code without "constexpr" and the fibonacci code might be an extreme case avoided by reasonable defaults for the numerous optimization parameters that can be adjusted:
max-inline-recursive-depth
max-inline-recursive-depth-auto
Specifies the maximum recursion depth used for recursive inlining.
For functions declared inline, --param max-inline-recursive-depth is taken into
account. For functions not declared inline, recursive inlining happens only when
-finline-functions (included in -O3) is enabled and --param
max-inline-recursive-depth-auto is used. The default value is 8.
I tried to watch the more interesting parts, it just doesn't seem like a useful approach to me to try to get the compiler to do this work at every compilation instead of the traditional approach of doing it once by generating C(++) code/structures from text/json data in my build. Especially with the "cognitive cost" and debugging issues involved.
Although ordinary functions can be evaluated at compile time without the constexpr annotation, only constexpr functions will raise an error if it _can't_ be evaluated at compile time (irrespective of if the compile thinks it should be). it's a judgement call for when explicit intent > implicit side-effects.
