P3953R1 - Rename std::runtime_format

Author: Victor Zverovich | Date: 2026-01-17 | Audience: LEWG

Paper link: wg21.link/p3953r1

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

There are only two hard things in Computer Science: cache invalidation, naming things, and getting LEWG to agree on what to name things.

This is the most LEWG paper of all time and I mean that as a compliment.

OK so I actually sat down and compared the naming options because this thread is going to turn into a bikeshed anyway, might as well be a structured bikeshed.

runtime_format - Established, shipped in implementations. Contradicts constexpr usage.

dynamic_format - Matches check_dynamic_spec. "Dynamic" overloaded in C++.

unchecked_format - Clear about what it does. Implies no checking, but there IS checking (just deferred).

deferred_format - Accurate re: deferred validation. Nobody says "deferred format string."

dynamic_format is the least bad option. The check_dynamic_spec alignment is the strongest argument in the paper - it means the format library already uses "dynamic" for this concept internally. The paper undersells this point.

The real distinction is not when formatting occurs, but how the format string is provided and validated.

The biggest gap in the paper: it doesn't seriously address unchecked_format as an alternative. "Unchecked" has precedent too. Victor probably has reasons but they're not in the paper.

Hot take: runtime_format is still the correct name.

"Runtime" in C++ naming doesn't mean "evaluated at runtime." It means "determined at runtime" - i.e., not a compile-time constant. We say "runtime polymorphism" for virtual dispatch. We say "runtime type information" for RTTI. Nobody argues those names are wrong because you can technically use them in consteval functions.

constexpr auto f(std::string_view fmt, int value) {
    // fmt is a "runtime value" - not a literal
    // the evaluation context doesn't change what it IS
    return std::format(std::runtime_format(fmt), value);
}

As a result, std::runtime_format can now be evaluated at compile time, making its name misleading.

The paper conflates "can be evaluated at compile time" with "is a compile-time value." Those are different things.

The problem with dynamic_format is that "dynamic" is already overloaded in C++:

- dynamic_cast - runtime type checking + conversion
- dynamic_pointer_cast - shared_ptr variant
- dynamic allocation - heap allocation
- dynamic linkage - shared libraries

In all of these, "dynamic" implies a runtime mechanism with overhead. dynamic_cast can fail. Dynamic allocation goes to the heap. The common thread is "runtime mechanism with cost."

std::dynamic_format isn't any of those things. It's just "I got this format string from a variable." We're borrowing a word that already means something specific in C++ and using it to mean something vaguer.

Meanwhile std::execution and networking continue to not exist. But sure, let's spend committee cycles renaming a function that works fine.

Worth noting this paper is by Victor Zverovich - the guy who created {fmt} and designed the API that std::format is based on. The original fmt::runtime() in {fmt} predates the standardized version. If anyone has standing to say "we named this wrong," it's him.

Though it's also worth noting that {fmt} itself still uses fmt::runtime(), not fmt::dynamic(). So even Victor's own library uses the old name.

Two revisions to rename a function. This is why C++ standardization takes forever.

just using dynamic_format = std::runtime_format; and stop letting the committee rename your code for you

In Rust the format string is always a literal and this entire category of problem doesn't exist. Just saying.