F-strings for C++26 proposal [pdf]
open-std.org
F-strings for C++26 proposal [pdf]
1–10 of 216 posts
Re: F-strings for C++26 proposal [pdf]
#2I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
Re: F-strings for C++26 proposal [pdf]
#3Tangent: this sort of thing can be implemented without any change to libc++ (the runtime). Updates to compiler versions are sometimes postponed by users with big codebases that treat a libc++ change as something major.
Why don't we see gcc or clang or msvc back porting stuff like this to an older version with a sort of future tag. It's normal to see __future__ in the python ecosystem, for instance.
Re: F-strings for C++26 proposal [pdf]
#4I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those
Re: F-strings for C++26 proposal [pdf]
#5I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
C++ also has std::format, which was introduced in C++20. This is just sugar on top of it, except it also returns a container type so that printing functions can have overloads that format into a file or stream directly from an f-string, instead of going through the overhead of a temporary string.
Re: F-strings for C++26 proposal [pdf]
#6I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
just skimmed the proposal, dont see how inline rendered f-strings are more complicated than the alternative.
Re: F-strings for C++26 proposal [pdf]
#7I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
So it's less complex bringing in a 3rd party library and having to pass arguments?
fmt library can also do something similar, but still requires the complexity of adding the library and passing arguments.
Re: F-strings for C++26 proposal [pdf]
#8Tangent: this sort of thing can be implemented without any change to libc++ (the runtime). Updates to compiler versions are sometimes postponed by users with big codebases that treat a libc++ change as something major. Why don't we see gcc or clang or msvc back porting stuff like this to an older version with a sort of future tag. It's normal to see __future__ in the python ecosystem, for instance.
If a codebase is fragile enough that libc++ changes have to be assumed breaking until proven otherwise, why take the risk? Presumably the application already has a "standard" way of formatting strings. If it ain't broke yada yada
Re: F-strings for C++26 proposal [pdf]
#9I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those
how would this work with internationalized strings? especially if you have to change the order of things? You'd still need a string version with object ordering I would think
Re: F-strings for C++26 proposal [pdf]
#10I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
So it's less complex bringing in a 3rd party library and having to pass arguments? fmt library can also do something similar, but still requires the complexity of adding the library and passing arguments.
especially bringing in boost which isn't allowed in some codebases