Still, it's a wasted opportunity not to have a language-level overload to the `switch` statement that allows nice pattern matching. Even with std::is_within_lifetime C++ unions are prone to errors and hard to work with.
Doing so takes the same space as a bool, and could be wrapped in a class if desired to provide a nicer interface.
I'm (fairly) sure there's a good reason for that language feature, but the justification the blog article gives is super weak.
The language is the problem, and WG21 hates fixing the language. The really bone headed stuff like "UB? in my Lexer?" got through as a language change and Barry has also had some success with "just fix it" language changes, that's what happened so that C++ can attempt what Rust's MaybeUninit<T> does, but mostly WG21 will take weird new intrinsics in the standard library, as here, over just fixing the programming language.
Notice that e.g. Rust doesn't prohibit compile time transmutation, the provided core::mem::transmute literally does this operation, and it's const. The result is - as with similar situations in C++ - that if at compile time that's a 2 the compilation fails, 2 is not a boolean. You don't need all this bother because Rust's type system is better so Option<bool> already does have the same size as bool, but that's beside the point.
What I was surprised with was that their union code was valid. I thought accessing a union member that was not active was valid in C, but not in C++.
Actually I can't think of a single realistic use case for this; despite the constant trumpeting of C++ folks on how constexpr will save C++, constant expressions are just too limited for this to matter.
Unless you have a system that says "no" a lot, and occasionally removes features, programming languages decay, and the game has been (historically, before LLMs) to pick a language that would be in the sweet spot for the time that you need to use it, while keeping your eye out for something else to switch to once it becomes sufficiently unusable.
They do publish removal plans years in advance, e.g. see Python 3.17's plans: https://docs.python.org/3/deprecations/pending-removal-in-3....
https://en.wikipedia.org/wiki/C%2B%2B11#Features_removed_or_...
https://en.wikipedia.org/wiki/C%2B%2B17#Removed_features
https://en.wikipedia.org/wiki/C%2B%2B20#Removed_and_deprecat...
https://en.wikipedia.org/wiki/C%2B%2B23#Removed_features_and...
.NET, the whole .NET Framework to modern (core) .NET migration, left several parts behind, the foor loop semantics change on C#, introduction of field keyword, and with.
Other than that, there's always an interesting psychology at play in software engineering but it really seems to come out when people talk about C++ for some reason. Complexity is just needless bloat when it's a feature you aren't using, and it's an essential part of the language when it's a feature you are.
41 years after its invention, C++ still doesn't have networking support in its stdlib. excuses after excuses, they have millions justifications on why the stdlib doesn't need networking. but in the same time, some bureaucratic "committee members" struggling with their midlife crisis want you to waste your life on stuff like Std:Is_within_lifetime in the era of AI.
what a bloody load of joke!
Can't wait to see some high accurate coding agents start being able to port C++ code to rust with minimum human interventions to liberate people from the most bureaucratic nonsense in CS history. Some AI native language incorporated with concepts that were too complicated for human would be even better.
it has never been a better time to depreciate dinosaurs like C++!
1: Some of networking is vocabulary and so it obviously should live in your stdlib, and indeed for C++ it should be in what they call "freestanding", like Rust's core, where core::net::IPv4Addr lives. It is very silly if the software in this cheap embedded device and this PC web browser can't even agree on what an IP address is in 2026.
2: In practice the C++ stdlib is used as a dumping ground for stuff that ought to live in a package manager if C++ was a good language. That was true when networking was first proposed and it's still true now. It's why RCU and Hive are both in C++ 26. Those aren't vocabulary, and they aren't needed by the vast majority of programmers, but their proponents wanted them to be available out of the box and in C++ that means they must live in the stdlib.
Networking is defacto in the standard library, because C++ standard library is almost always supplemented by whatever C functionality is lying around, and POSIX networking exists.
That they haven't felt the need to provide a more useful abstraction on top of the POSIX layer (and hey, maybe abstract over Microsoft's variant in the process) in the past 3 decades does seem like a miss
It'd be funny if it ends up being just C++35.
C Source code => Tradicional UNIX C compiler => ASM => object file
Now everyone is doing
AI tooling => C Source code => Tradicional UNIX C compiler => ASM => object file
For all pratical purposes, just like using a language like Nim, the workflow exposed to user can hide the middle steps.
Then there is the other take, if you start using agents that can be configured to do tool calling, it is hardly any different from low code applications, doing REST/GraphQL/gRPC calls orchestrated via flow charts, which is exactly what iPaSS tooling are offering nowadays, like Workato, Boomi,...
For most of us it seems you can get good at C++ or metaprogramming. But unless you want to make it your entire career you can't really do both with the same degree of effectiveness.
I really like C++, and I will probably continue using it forever. But really only the very small subset of the language that applies to my chosen field. I'm a "C with classes" kind of guy and templates and constexpr are pretty rare. Hell, half the time I don't even have stdlib on embedded platforms. It's kind of nice, actually.
template<bool condition>
void method () { .... if (condition) /* constexpr */ { extra_code; } .... }
>It is — and it totally makes sense.
Average C++ enyojer coping mechanism on C++ trend of naming things with the most convoluted (and often wrong) way possible. std::vector, std::monostate, std::unit, etc.
eptcyka•1h ago
bvrmn•29m ago