constexpr math needs rules for errors and rounding
P0533R6 proposes a bounded extension of constant evaluation into cmath and cstdlib. Runtime environment dependencies explain why the proposal selects some functions and excludes others.
Making a mathematical function usable in a constant expression requires more than adding a declaration specifier. The function may report an error through runtime state, or its answer may deliberately depend on a rounding mode chosen during execution. Edward and Oliver Rosten's P0533R6, dated April 14, proposes criteria for extending constexpr into cmath and cstdlib while keeping those dependencies bounded.
The paper's scope is deliberately smaller than every mathematical function. It uses closure over rational numbers and the absence of strong rounding-mode dependence as selection criteria. Functions such as square root and trigonometric operations fall outside this proposal's selected set.
Compile-time computation interests me as another way C++ moves work out of runtime execution. The implementation burden and the numerical contract still matter. A computation performed earlier needs a defined meaning, including what happens when its arguments make the mathematical operation invalid.
An invalid constant expression is a different outcome
At runtime, a library function can have an established way to report a numerical error. A required constant expression cannot simply depend on later inspection of runtime error state. The compiler needs to determine whether the expression satisfies the constant-expression rules.
P0533R6 proposes that a C-library call encountering a domain error or overflow cannot be part of a core constant expression. That gives the constant-evaluation case a clear rejection condition while preserving ordinary runtime behavior outside that context.
The distinction is practical for generated constants. A program may want to compute a value during translation because another declaration requires it. If the computation is invalid, rejecting that declaration is more informative than silently manufacturing a value whose error report the program cannot inspect in the intended context.
This does not require every call to a constexpr function to happen during translation. The same interface can remain useful for runtime arguments. The declaration permits constant evaluation where the rules allow it, rather than turning the function into an instruction to execute every invocation early.
Rounding has more than one role
The proposal distinguishes rounding caused by limited floating-point precision from functions whose purpose explicitly depends on the active rounding mode. That separates a numerical representation issue from an intentional dependency on runtime configuration.
Consider an operation whose mathematical answer is not exactly representable. Some rounding is unavoidable when the program stores its result in a finite representation. A function explicitly designed to consult a selected rounding mode carries a further dependency, because the choice of mode is part of its requested behavior.
Constant evaluation needs an account of both cases. It cannot simply assume that a runtime environment already exists in the form an application will later configure. The paper excludes strongly dependent functions while relating the weaker case to arithmetic operations already usable in constant expressions.
That provides a reason for the selected scope. A proposal can make useful progress by adding functions with a manageable relationship to existing evaluation rules. It does not need to claim that every function in the header has the same requirements.
A separate implementation can preserve one interface
The paper discusses std::is_constant_evaluated as a possible implementation tool. The earlier P0595R2 explains how that facility distinguishes specified constant-evaluation contexts. Its purpose includes selecting a constant-expression-friendly implementation while retaining another implementation for runtime use.
This is useful because the best implementation can depend on the context. Runtime code may call an optimized library operation whose implementation is unsuitable for constant evaluation. A constant-evaluation path can use operations that the compiler can evaluate under the language rules.
The important requirement is semantic consistency. Choosing different algorithms should preserve the documented result within the operation's requirements. A context query is an implementation mechanism, not permission to give callers unrelated numerical behavior.
It also needs to remain separate from ordinary optimizer folding. A compiler may simplify a runtime expression because its inputs are known. That optimization does not by itself establish that the source expression meets a language requirement for a constant expression.
A numerical subset still has practical uses
A selected set of constant-evaluable functions can let an application express derived values without maintaining an independent implementation solely for translation-time use. The source can state the mathematical operation in the same vocabulary it uses elsewhere.
That reduces one opportunity for divergence. If runtime and translation-time source use unrelated helper implementations, changes to one can leave the other with different assumptions. A common standard interface gives the program a clearer contract, even when its implementation internally selects different algorithms.
I prefer that bounded contract to a broad claim that compile-time math is already solved. P0533R6 identifies which operations it intends to cover and explains why runtime state excludes others. Its practical contribution is to make more numerical declarations possible under explicit error and rounding rules.