Okay, so treat the C++ standards committee the same way the HTML5 people treated W3C. If they insist on making themselves irrelevant, let them.
Profiles cannot achieve the same level of safety as Rust and it's obvious to anyone who breathes. Profiles just delete stuff from the language. Without lifetimes reified as types you can't express semantics with precision enough to check them. The moment string_view appears, you're horked.
Okay, so you ban all uncounted reference types too. Now what you're left with isn't shit Rust but instead shit Swift, one that combines the performance of a turtle with the ergonomics of a porcupine.
There's no value in making things a little bit safer here and there. The purpose of a type system is to embed proofs about invariants. If your system doesn't actually prove the the invariant, you can't rely on it and you've made is a shitty linter.
Continue the safe C++ work outside the context of the C++ standards committee. Its members, if you ignore their words and focus on the behaviors, would rather see the language become irrelevant than change decades old practices. Typical iron law of bureaucracy territory.
The reason why WHATWG was able to take over HTML like that is because all the people & companies that were actually making the browsers were onboard.
With C++, my impression is that most implementers simply aren't interested. And, conversely, most people who might be interested enough to roll a new implementation have already moved to Rust and make better use of their time improving that.
The browser companies weren't just onboard with WHATWG – they literally are WHATWG. The WHATWG steering committee is Apple, Google, Microsoft, and Mozilla.
You right, because the main companies with OSes that contribute to the surviving compilers that still care about ISO, are now focused elsewhere.
Apple with Swift, Google with Go, Java/Kotlin, Rust, Microsoft with C#, Go, Java and Rust.
Most modules stuff on GCC was done by a single developer, if I am not mistaken.
Notice how Visual C++ blog posts are mostly about game development related improvements, Visual Studio tooling.
Everyone else their compilers are still stuck on C++14, or C++17 if lucky.
You're right, but dammit, I wish you weren't. A world in which we can evolve existing large C++ codebases gradually towards safety instead of having to RRiR is a better world.
There are lots of cool innovations C++ made that will just disappear from the Earth, forever, if C++ can't be made memory safe in the same sense Rust is. I mean, Rust doesn't even support template specialization.
I don't think it's too late for someone to fork both C++ and Clang and make something that's actually a good synthesis of the old and the new.
But yeah, the most likely future is one on which C++ goes the way of Fortran (which still gets regular updates, however irrelevant) and the energy goes into Rust. But I like to rage, rage, against the dying of the type based metaprogramming.
> I don't think it's too late for someone to fork both C++ and Clang and make something that's actually a good synthesis of the old and the new.
People have tried variants of this already: Carbon, for example. I don’t think anyone outside of Google uses it, though, and even within Google I suspect it’s dwarfed by regular C++.
I don’t think C++ will become irrelevant for a long time. Recent standards have added some cool new features (like std::expected), and personally I feel like the language is better than ever (a biased opinion obviously).
Memory management is still a huge elephant in the room, but I don’t think it’s becoming irrelevant.
Carbon is still being designed, and their goal is to migrate existing code, for Google purposes.
They are quite open everyone else should use a managed language or Rust.
FWIW, Rust doesn't have specialization yet because they're really hard to get right without introducing new undefined behaviors.
This doesn't mean that it's not possible to achieve a safe subset of C++ that supports template specialization, but it suggests that we aren't going to see it any time soon.
Well like you said, Fortran didn't actually go anywhere. Fortan 77 is a terrible programming language, but you can't seriously claim it "disappeared from the Earth".
Not that long ago tsoding was like "I should learn Fortran" and wrote a bunch of Fortran. Obviously from his perspective some things about Fortran are awful because it's very old, but it wasn't somehow impossible to do.
There are a few really amazing things which have been achieved in C++ like fmt, a compile time checked, userspace library for arbitrarily formatting variadic generic parameters. That's like man on the moon stuff, genuinely impressive. Mostly though C++ is a garbage fire and so while it's important to learn about it and from it we should not keep doing that.
> There are a few really amazing things which have been achieved in C++ like fmt, a compile time checked, userspace library for arbitrarily formatting variadic generic parameters.
Anecdotal, but that's hardly unique to C++. So even if C++ were to disappear overnight (which we all agree won't happen), this wouldn't be a burning-library-of-Alexandria moment.
Well. What other examples of this feat are you thinking of?
To me the things which come to mind are either compiler magic (e.g. C printf) or they rely on RTTI (e.g. Odin and similar C-like languages) and neither of those is what fmt does, they're "cheating" in some sense that actually matters.
I co-implemented this in OCaml ~20 years ago, using no compiler magic (it did use a macro). Pretty sure that I've seen the equivalent in Haskell, too, and in variants of Scheme. Zig has it, too. And while, as you mention, the Rust implementation does use compiler magic, I'm pretty sure that it could be implemented as a macro, just more slowly.
etc.
(sorry, it wasn't you who mentioned it, but it was a good remark nevertheless :) )
https://doc.rust-lang.org/std/macro.format.html
https://zig.guide/standard-library/formatting/
Rust is an example of "compiler magic" in this case.
You're right about Zig, and reading the source [1] I'm still kind of impressed how unified they made comptime / runtime.
[1]: https://github.com/ziglang/zig/blob/32a1aabff78234b428234189...
Judging Fortran by looking at Fortran 77 is preposterously uninformative.
What should we be looking at ?
If we're judging the state of Fortran in 2025, we should probably be discussing Fortran 2018 or Fortran 2023.
> fork both C++ and Clang
Great! What are you waiting for?
If you try to answer that question, you'll also find why other similar projects are not finding much traction yet.
> Profiles cannot achieve the same level of safety as Rust
So the claim is that the scpptool approach[1] can, while remaining closer to traditional C++, and not requiring the introduction of new language elements. Since the scpptool-enforced safe subset of C++ is an actual subset of C++, conforming code continues to build with your existing compiler. It just uses an additional static analyzer to check conformance.
For the 90% or whatever of C++ code that is not actually performance sensitive, the associated SaferCPlusPlus library provides drop-in and "one-to-one" safe replacements for unsafe C++ elements (like standard library containers and raw pointers). (For example, if you're worried about potentially invalid vector iterators, you can just replace your std::vector<>s with mse::mstd::vector<>s.) With these elements, most of the safety is enforced in the type system and not reliant on the static analyzer.
Conforming implementations of performance-sensitive code would be more restricted and more reliant on the static analyzer for safety enforcement. And sometimes requires the use of library elements, like "borrowing objects", which may not have analogies in traditional C++. But overall, even high-performance conforming code remains very recognizable C++.
The claim is that the scpptool approach is a straightforward path to full memory (and data race) safety for C++, and the one that requires the least code migration effort. (And again, as an actual subset of existing C++, not technically dependent on standard committees or compiler vendors for its implementation or deployment.)
[1]: https://github.com/duneroadrunner/scpptool/blob/master/appro...