F-strings for C++26 proposal [pdf]

Role and Benefits of C++ F-strings

• Proposed as sugar over std::format: f"..." yields a basic_formatted_string (reified arguments) instead of std::string.
• Main gain: avoid intermediate allocations and allow APIs (e.g., logging, serial consoles, freestanding/embedded) to format directly into sinks or background threads.
• Several commenters liken it to Rust’s format_args! and C#’s interpolated strings / FormattableString.

Complexity vs. Convenience

• One camp: adding a feature that simplifies everyday string formatting is worth extra language complexity; C++ is already too big to fully grasp anyway.
• Opposing view: every new core feature increases edge cases, learning burden, and pushes more “patch features” (like decay proposals) to fix problems introduced by earlier ones.
• Broader debate spills into whether post‑C++11 features (concepts, ranges, move, constexpr, etc.) are genuine improvements or mostly complexity to fix template/iterator/design shortcomings.

Type, Lifetime, and “Decay” Problems

• f"..." does not produce std::string, so:
  • auto s = f"..."; gives a basic_formatted_string, which may contain dangling references.
  • Implicit conversions break where today a std::string would convert further (e.g., to std::filesystem::path).
• Follow-on proposals (decays_to, user-defined type decay, explicit auto) aim to make f-strings silently “decay” to std::string in common cases, while still allowing reference-like behavior when explicitly requested.
• Critics see this as piling on complexity to work around lack of robust lifetime safety; Rust is cited as an example where such misuse simply doesn’t compile.

Safety, Pointers, and the Standard Library

• Broader thread about C++ safety: smart pointers exist, but much of the standard library still uses raw pointers/references, so ownership and borrowing remain implicit.
• Some argue C++ has “basic safety features” that programmers choose not to use; others respond that the ecosystem and standard APIs don’t consistently encode ownership, so dangling and use‑after‑free remain easy.

Internationalization Concerns

• Translators typically manipulate format strings and reorder arguments; C++ f-strings are compiled expressions, not just data.
• Concern that _ ( f"...{x}..." ) can’t be extracted or safely edited by translators; suggestion that for translatable strings you may need to avoid f-strings or use APIs that accept basic_formatted_string and translate before formatting.
• Some argue i18n is out of scope for f-strings; others say the proposal should at least acknowledge this limitation.

String Syntax and Alternatives

• Comparisons with Python (multiple literal types, escaping, embedded “format mini-language”) and Swift (single unified interpolation model using backslash and configurable # delimiters).
• Some see Python’s f-strings as a success; others call them a “mess” compared to Swift’s cleaner design and wish C++ had studied that model.