Decline based on usage of pascalCase in the first example. How did that even happen?
That isn't even PascalCase. This is camelCase.
F-strings for C++26 proposal [pdf]
61–70 of 216 posts
Re: F-strings for C++26 proposal [pdf]
#62So the f-string literal produces a basic_formatted_string, which is basically a reified argument list for std::format, instead of a basic_string. This allows eg. println to be overloaded to operate on basic_formatted_string without allocating an intermediate string std::println("Center is: {}", getCenter()); std::println(f"Center is: {getCenter()}"); // same thing, no basic_string allocated In exchange we have the fo…
This seems pretty similar to Rust's `format_args!` macro, which however avoids these issues by being much more verbose and thus something people are less likely to use like in those examples. It does however have issues due to the abundant use of temporaries, which makes it hard to use when not immediately passed to a function. I wonder if C++'s fstrings have the same issue.
Re: F-strings for C++26 proposal [pdf]
#63So the f-string literal produces a basic_formatted_string, which is basically a reified argument list for std::format, instead of a basic_string. This allows eg. println to be overloaded to operate on basic_formatted_string without allocating an intermediate string std::println("Center is: {}", getCenter()); std::println(f"Center is: {getCenter()}"); // same thing, no basic_string allocated In exchange we have the fo…
Hah. What's interesting about this is that since it doesn't require everything to actually be converted to a string, one can implement things other than just printing. So you could also implement interpretation, eg:
pylist = python(f"[ y*{coef} for y in {pylist} if y > {threshold}]")Re: F-strings for C++26 proposal [pdf]
#64So the f-string literal produces a basic_formatted_string, which is basically a reified argument list for std::format, instead of a basic_string. This allows eg. println to be overloaded to operate on basic_formatted_string without allocating an intermediate string std::println("Center is: {}", getCenter()); std::println(f"Center is: {getCenter()}"); // same thing, no basic_string allocated In exchange we have the fo…
> There are two other proposals to fix these problems.
Most new features of C++ are introduced to fix problems created by previously new features added to C++.
Re: F-strings for C++26 proposal [pdf]
#65Is it a coincidence that all these quality life things start to pop up after C++ is facing real competition for the first time? Seems a bit odd to add print after using std::out for 30 years.
Re: F-strings for C++26 proposal [pdf]
#66Is it a coincidence that all these quality life things start to pop up after C++ is facing real competition for the first time? Seems a bit odd to add print after using std::out for 30 years.
What is this referring to? I would imagine whatever you consider recent competition is actually not that recent.
Re: F-strings for C++26 proposal [pdf]
#67Making any changes to the core language is a sensitive thing as it inevitably imposes new demands on compilers, a learning curve for all users of the language, and risks breaking compatibility and introducing unforeseen issues that will need to be fixed with future changes to the language.
Personally, I'd much prefer a smaller and more stable language.
Re: F-strings for C++26 proposal [pdf]
#68Is it a coincidence that all these quality life things start to pop up after C++ is facing real competition for the first time? Seems a bit odd to add print after using std::out for 30 years.
What is this referring to? I would imagine whatever you consider recent competition is actually not that recent.
On the time scale of c++, rust is very recent. :-)
Re: F-strings for C++26 proposal [pdf]
#69Earlier quoted context omitted.
Office team apparently is of another opinion, as Vulkan folks, and a few other early adopters. You could just as well say that anything beyond C89 doesn't exist, given its prevalence in some circles.
Yes. There are a very small handful of early adopters in the year 2025 for a feature ostensibly added in C++20. So, like I said, modules don’t exist in practice and I’d be shocked if in 2030 modules were considered normal. C++11 was pretty game changing. C++14 and C++17 only took a few years to reach widespread adoption. It’s very safe to require C++17 today. C++20 was a little slower and because of the modules fucku…
Like I said, it is a matter of point of view, and yes such is the karma of ISO driven languages with multiple implementations, when one cares about cross platform code.
There are many folks that don't care though, for them it is "one platform, one compiler, language standard is whatever my compiler allows me to do, including extensions".
I am also quite bullish on the opinion that eventually, C++26 might be the last standard, not that WG21 will stop working on new ones, rather that is what many will care about when using C++ in a polyglot environment, as it is already the case in mobile OS platforms, the two major desktop platforms and distributed computing (CNCF project landscape).
Why C++26 and not earlier? Reflection.
Re: F-strings for C++26 proposal [pdf]
#70Making any changes to the core language is a sensitive thing as it inevitably imposes new demands on compilers, a learning curve for all users of the language, and risks breaking compatibility and introducing unforeseen issues that will need to be fixed with future changes to the language. Personally, I'd much prefer a smaller and more stable language.
Leaving curve can decrease as a result of better design, same re. the chance of those unforeseen issues (and it can even decrease the chance of existing bugs popping up)