(2) is a point I firmly agree with (though not everyone does), but it’s a hard one.
Here’s the way I think about it. I don’t think I’m wrong but I’m absolutely open to being told otherwise.
C++ is a language. It has a standard library. The library depends on the language, but the language shouldn’t depend on the library. This is because many applications cannot use the standard library, or parts of it.
The conceptual issue with fstrings in C++ is that the formatting is done on a library level. An fstring would be a language feature. It wouldn’t be reasonable for syntax sugar to resolve to a library call.
So what we’d need is a way of having parameterised strings that the language knows to separate out into parameters in a function call. For instance:
f(f”Hello, {planet}”);
would resolve to:
f(“Hello, {}”, planet);
such that replacing f with std::format, std::print (C++23), fmt::format, fmt::print, spdlog::info, spdlog::error, or even scn::scan (?), would do exactly what you want.
However, the expression f”Hello, {planet}” would be meaningless on its own, and care would need to be taken to avoid:
I wonder/doubt if the comma would have to be an explicit step as part of the hand over to the std lib. The comma is a separator that the programmer would use, but does the compiler need that? The compiler needs to translate 1 argument to multiple arguments of multiple types, such that stdlib can receive all info. (The original fstring indeed cannot be expanded by the lib itself, since that would give stdlib a special status). So the needed language feature is a one to multi args translation, where at compile time all types are known. That would mean that in the context of an assignment (in stead of a function argument), the f string does not make sense. In that case the compilation can simply fail, no?
I guess the handing over the multiple args of different types is a problem. Not all infinite combinations can be solved by templating and I guess even if it could, the header would contain too much logic since the template expansion needs to happen from the header?
Here’s the way I think about it. I don’t think I’m wrong but I’m absolutely open to being told otherwise.
C++ is a language. It has a standard library. The library depends on the language, but the language shouldn’t depend on the library. This is because many applications cannot use the standard library, or parts of it.
The conceptual issue with fstrings in C++ is that the formatting is done on a library level. An fstring would be a language feature. It wouldn’t be reasonable for syntax sugar to resolve to a library call.
So what we’d need is a way of having parameterised strings that the language knows to separate out into parameters in a function call. For instance:
f(f”Hello, {planet}”);
would resolve to:
f(“Hello, {}”, planet);
such that replacing f with std::format, std::print (C++23), fmt::format, fmt::print, spdlog::info, spdlog::error, or even scn::scan (?), would do exactly what you want.
However, the expression f”Hello, {planet}” would be meaningless on its own, and care would need to be taken to avoid:
std::string x = f”Hello, {planet}”;
from resolving to:
std::string x = “Hello, {}”, planet;
Which would be equivalent to
std::string x = planet;
Thanks to C++‘s ludicrous comma operator.