I wanted to write to seek broader feedback and relay my experience trying
to leverage constexpr in a real-world situation where compile-time
computation is a requirement for performance. By way of a brief background,
I am working on an library that computes expressions over
higher-dimensional data types. The math itself isn't important for the
purposes of this discussion, but compile-time techniques allow me to
"collapse" higher dimensional data into sparse representations without
needing runtime annotation. When working with expressions, authors of ETLs
know that expressions can explode dramatically.

For example, if I encode a polynomial using templates (variables,
monomials, and degrees) via parameter packs as some type P and later try to
do a 4th order taylor expansion (just as an example), the number of terms
will increase as O(N^4). I quickly found that templates were untenable due
to memory and processing constraints (instantiating too many types, etc).
This is *despite* aggressive usage of folds and ensuring that parameter
packs had an imposed total order to minimize instantiations. Under this
approach, is was astonishingly easy to completely cripple the compiler even
for cases I would consider easy (clang profiling was tried, as well as
general profiling tools). Again, this is code that runs perfectly fine at
runtime, but the cost could easily be moved to compile time.

Thus, the next option is to leverage constexpr, encoding expressions as
actual member data, and using templates solely to encode the size of the
data. Folds become loops, and in principle, compilation time and memory
usage should go down. Here are the things I encountered along the way:

1. The compiler is "dumb" in the sense that data that is entirely compile
time deterministic is not usable as such. Going back to the example of
polynomials. Suppose the number of addends in each is N1 and N2. Upon
addition, the sum is *at most *N1 + N2, however, it is possible that some
of the monomials combine. Trying to express this using any form of
constexpr is extremely difficult. Common strategies include traversing the
data twice (once to compute the size, a second time to actually compute
it). In this case, the data itself is not encoded in types, and so this is
not possible (despite, again, all the data being compile-time
deterministic).

2. I have found that constexpr can ironically decrease performance in a
number of situations. Once code was restructured as constexpr, the compiler
often fails to inline code that should be entirely inlineable. Suppose we
want to actually attach data to what is now a compiled expression template.
All early attempts to do so failed because the compiler was unable to infer
that the instantiation of the function could only possibly be invoked in
one place (and thus should be inlined no questions asked). Part of the
issue here is that constexpr as a keyword conveys *very little
information* regarding
what will ultimately happen when invoked. By the time I restructured the
code to peel away the non-constexpr argument that had snuck in, the compile
times became untenable again (once again, more data needed to be pushed to
types) and it was back to the drawing board.

3. The proper usage of `if constexpr` feels a bit lackluster. The operand
must be fully determined to be a constant expression, but this immediately
qualifies "data" that is, again, static at compile time. Constant
expression arguments proposed for C++2b is an option, but it should seem
that an if block gated by the `is_constant_evaluated` should preclude that
(it doesn't). Another issue is that in more complicated functions, it can
be very difficult to reason about the branches when constexpr and
non-constexpr branches must intermingle.

4. Allowing allocations which do not leave the constexpr context via
constexpr new is not actually helpful in several situations I can think of.
At the end of the data, often, the data needs to be variably sized, and in
this scenario, you cannot use auto return type deduction to read off the
size as a constant expression and create the appropriately sized type that
I need.

Are there situations and workarounds to the above? Yes, but only after
extensive rewrite and fighting the compiler every step of the way. Even at
the end, I'm not sure if I will be getting the performance I could have
gotten with just straight C-style procedural code for each operation I need
to support. Granted, I think my application was perhaps a bit more extreme
in its requirements, but I think it was a decent "sniff"-test for what I
see as problems and headaches ahead. As it is, I'm doing things like
rounding up capacities to the nearest size of two (and other such nonsense)
to reduce the combinatorial explosion of type instantiations.

*The idea I would like to float around is the following:*

- Proposal: introduce a new function signature decorator called `consteval`
(in the spirit of the variable consteval decorator) which is an input into
overload resolution.
- All other overload resolution decorators are evaluated first (const, ref
qualifier, ADL), and then `consteval` is considered. If the invocation
occurs at compile time, the `consteval` overload is given precedence.
- All arguments passed to the consteval function are *implicitly constexpr *by
definition
- All if statements and control statements are similarly implicitly
constexpr (even if the notion for such a construct doesn't exist now, i.e.
there is no `for constexpr` as of yet).
- Functions that are `consteval` can call non-consteval functions without
any issue (it is a weaker qualification).
- All allocations are also permitted applying the rules with the currently
proposed `constexpr new`, except *they may leave *the constexpr context and
reside in the data segment (analogous to static variable initialization).
Initially, I would imagine that only trivial destructors are permitted (but
still this would unlock a lot of capability).
- All data mutated in the consteval context are also considered "constant
expressions" when referenced later.
- Ergo, consteval produces an easy-to-reason about "frontier" of constant
expressions. In conjunction with consteval as a variable decorator, there
is no guesswork as to what will happen at compile time and what won't
- We dramatically simplify code and no longer need specific constexpr
variants of various control structures and littered code with conditionals
to activate "compile-time-only" code.
- If we want to share functionality, we can introduce a common entry point
that does not have the `consteval` qualifier.

The theme of the idea is simple. Code that is C++ should just be C++, and
how it behaves at compile time and runtime should differ by at most a
keyword. I think such a feature is far easier to reason about (and to
teach, just piggy-backing off general overload resolution principles),
without overcrowding the API (at our current rate, we'll have a
constexpr-paper variant for every language feature in C++). I would not
propose deprecating any existing functionality immediately, but tbh, if I
had something like `consteval` today, I would outright ban constexpr in my
codebase.

Important: I don't (even remotely) claim that the above has worked out all
the details, or that there aren't issues I haven't thought of. These are
just thoughts that I kept coming back to now that I've had much more
extensive experience working with constexpr (compared to just dotted
isolated cases in the wild before). My standardese is weak, having never
written a paper, so consider this primarily as a perspective from the lens
of a practitioner.

Thoughts/feedback appreciated,
Jeremy