There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Karlton
1. Abstract
[P2918] introduced to allow opting out of compile-time
format string checks in . Subsequently, [P3391] made usable in constant evaluation. As a result, can now be evaluated at compile time, making its name misleading. This paper
proposes renaming to to better
reflect its semantics and avoid confusion in contexts.
2. Motivation
The name was accurate when introduced in [P2918], as
format strings were not usable in constant evaluation. However, with the
adoption of , the term runtime no longer reliably
describes the behavior of .
Consider the following code:
constexpr auto f ( std :: string_view fmt , int value ) { return std :: format ( std :: runtime_format ( fmt ), value ); }
Despite its name, can be evaluated at compile time.
This creates a semantic mismatch:
-
"runtime" suggests evaluation timing
-
The facility actually describes how the format string is obtained.
The real distinction is not when formatting occurs, but how the format string is provided and validated. The term runtime conflates it with evaluation time.
3. Proposed Naming: std :: dynamic_format
The proposed name reflects the actual semantics:
-
The format string is dynamically provided
-
The format string is not a compile-time constant
-
The validation is deferred (but may still occur during constant evaluation)
This aligns with existing terminology such as dynamic format
specifiers ().
Example with proposed name:
constexpr auto f ( std :: string_view fmt , int value ) { return std :: format ( std :: runtime_format ( fmt ), value ); }
This reads naturally and avoids semantic contradiction.
4. Impact on existing code
If this is adopted for C++26 there will be no impact on existing code since is a C++26 feature.