Reinventing C#’s FormattableString and interpolated string handlers :)
C# wasn't the first language which introduced such mechanism.
F-strings for C++26 proposal [pdf]
71–80 of 216 posts
Re: F-strings for C++26 proposal [pdf]
#72Earlier 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…
> C++20 and beyond haven’t added much that’s worth upgrading for.
std::format is pretty nice (although not yet available on Ubuntu 24.04 LTS.
Lambda capture of parameter packs is actually huge!
And ... I think it still remains to be see what the outcome of modules will be.
One hopes (against hope) that the big payoff for modules will be in tool-ability of C++. IDE support for languages like C#, Java, typescript is vastly superior to C++ IDE tooling. Perhaps. Maybe. Modules will provide a path that will allow that to change. I don't think the benefits of modules have yet fully played out.
Re: F-strings for C++26 proposal [pdf]
#73Earlier quoted context omitted.
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…
> Reflection
Oh yes please! :-)
Re: F-strings for C++26 proposal [pdf]
#74So 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++.
This is becoming such a tiresome opinion. How are concepts fixing a problem created by previous features to the langue? What about ranges? Auto? Move semantics? Coroutines? Constexpr? Consteval? It is time for this narrative to stop.
Re: F-strings for C++26 proposal [pdf]
#75So 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…
One of the two other proposals is user defined type decay, which lets you choose what type auto will be deduced as. i.e. "auto x = y", x might not have the type of y, instead it can be anything you choose…
This is like implicit type conversion on steroids. And all this because C++ lacks the basic safety features to avoid dangling pointers.
Stop using C++ already!
Re: F-strings for C++26 proposal [pdf]
#76Earlier quoted context omitted.
> 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++.
This is becoming such a tiresome opinion. How are concepts fixing a problem created by previous features to the langue? What about ranges? Auto? Move semantics? Coroutines? Constexpr? Consteval? It is time for this narrative to stop.
Honestly can't tell if this is sarcasm. XD
Re: F-strings for C++26 proposal [pdf]
#77Somehow I manage to get by just fine with c++11. I have refactored more than a few codebases that use 17 or greater. Strangely, the codebase became more maintainable afterwards.
C++20's concepts IMHO are a massive update over C++11. You can basically remove almost 90% of inheritance with them without incurring in any issue (you could do that earlier too, but at the expense of incredibly hard to read error messages - now that's basically solved thanks to concepts).
I don't find the error messages produced by concepts much better than old school template errors. Maybe I got used to the latter with experience and definitely the compilers got better at generating useful error messages for templates as the years passed. On the other hand when I have to review code where a significant portion of the source relates to concepts, my heart sinks.
In my opinion, C++ "concepts" are the least useful C++20 addition to the language - awful syntax, redundancy everywhere (multiple ways of writing the same thing). And for what? Potentially better error messages?
Another gripe; of all the generic overloaded words available to describe this C++ feature, "concept" must be the least descriptive, least useful. Why pick such a meaningless name that does absolutely nothing to even suggest what the feature does?
Re: F-strings for C++26 proposal [pdf]
#78Jesus. This is such a bad idea. Don't repeat the mistakes of Python. Look at what Swift does and make a SANE system ffs.
Re: F-strings for C++26 proposal [pdf]
#79So 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…
One of the two other proposals is user defined type decay, which lets you choose what type auto will be deduced as. i.e. "auto x = y", x might not have the type of y, instead it can be anything you choose… This is like implicit type conversion on steroids. And all this because C++ lacks the basic safety features to avoid dangling pointers. Stop using C++ already!
Smart pointers were added to the language 14 years ago. You're free to use old C++ with raw pointers and manual memory management, risking dangling pointers, or use modern C++, which provides smart pointers to avoid those issues.
Re: F-strings for C++26 proposal [pdf]
#80Earlier quoted context omitted.
Off the top of my head, C++17 brought slicker notation for nested namespaces, digit separators for numeric literals (so you can more easily read 1'000'000'000), improvements in type deduction for pairs / tuples (so std::make_pair / make_tuple are basically unnecessary now), guarantees in the standard for copy elision / return value optimization in specific circumstances,. Oh, and structured bindings (so you can now w…
Designated initializers are so nice. Even though they have C++-isms like required order, it adds safety and readability to code.
The safety and readability are nice; but WHY do they have to be in order? That is so typically clueless. Such an obvious feature, screwed up in a way that only a C++ committee member could.