This is pointless for corporations with 40 years of code in production.
Changing all those 40 years worth of code to the safe subset is equivalent to a total rewrite. Especially since usually the really old parts of the code have never been touched or modernized, so are usually C-like and therefore very far away from the safe subset.
One might as well rewrite it in something properly memory-safe.
I agree that this proposal isn't great. But also that you're not responding to what the comment is really saying - it's responding to the "just use rust" suggestion. If Rust is a good choice, great. But that doesn't mean we should abandon all attempts to improve standardization of C++. And I mean "attempts" - production conversation should be around why something doesn't work and why it fails, "just use rust" is not really relevant here. It's perfectly fine to say when starting a new project or figuring out how to rewrite an existing codebase, but in a conversation about C++ standards it's just not relevant.
I like Rust and very happy it's being used more and more. I am just tired of it constantly coming up in any talks about C++ on HN.
Especially when building the Rust compiler, at least for the time being, requires C++, and many domains Rust wants to play only have C and C++ based industry standards like Khronos APIs, CUDA, consoles,...
That transition from C to C++ isn't really the same kind of transition. When moving over to C++ from C, you get to keep and use all your old code and gain new capabilities for the newly-written parts. Extending stuff like this is easy.
Moving to a subset is very hard, because you loose capabilities. And since this is about memory-safety, you either loose them all at once, or you aren't really memory-safe until you migrated all your codebase to the subset.
So while C->C++ takes 40 years, you get benefits in pieces during the 40 years of migration. With C++->SafeC++, you can only get those benefits at the end of those 40 years. Which usually means that it won't be done at all.
What might be a possible approach is to divide a huge codebase into smaller parts, isolate them from each other (microservices if you want to call it that) and then migrate those smaller parts to SafeC++. But since that would change the whole architecture of the codebase, the viability is always a very big "maybe".
> you aren't really memory-safe until you migrated all your codebase to the subset.
That's true for every gradual migration, even to another language. At the limit any rust code that uses 'unsafe' is not really memory safe for small values of 'really'.
Perfect is the enemy of good. An incremental improvement to the status quo is still an improvement.
Although I'm firmly in the "I'll believe [the practicality] when I'll see it" camp, I'm all in favour of these experiments with memory safety.
It is still much easier to sell than throw away, rewrite in Rust, while the ecosystem is full of growing pains, and not yet taken seriously in many industry critical standards.
Changing all those 40 years worth of code to the safe subset is equivalent to a total rewrite. Especially since usually the really old parts of the code have never been touched or modernized, so are usually C-like and therefore very far away from the safe subset.
One might as well rewrite it in something properly memory-safe.