[tobias12345]

I am disappointed:

I have to wait a few years for the C++ committee to define profiles. Then a few more years for tooling to become available. Then a few more months for the tooling to become interoperable enough to actually be used in existing build tooling. Then a few more years for all my major dependencies to actually use profiles. Then I can rewrite my code in profiles-C++ -- or by writing safety wrappers around my existing code and all dependencies that do not support the right profiles.

Or I can switch to a memory safe language today. I still have to write safety wrappers around all my code to interface with that, but I'll have a couple of years of a head-start to anybody sticking to C++.

[burjui]

IMHO, really there are no options for this idea other than to be disappointing. C++ is already a monster, way too complex and complicated, and unless one decides to revamp it from the ground up, effectively coming up with a different language that is no longer C++, the only way to improve the safety is to make C++ even more complex and complicated. I think in 202x's it's time to let it go, to stop layering complications and inconsistencies on top of one another. To continue trying to "fix" C++ is to continue to feed the sunk cost fallacy.

[pjmlp]

Not everyone has that option, thus we need to also improve C and C++.

As an example, while Microsoft slowly adopts Rust, it keeps putting out best practices and improved tooling, they aren't going to rewrite the whole Windows, XBox and Azure C++ code into Rust for the next couple of decades, or how long they would still matter on the market place.

Or Apple with they increased adoption of Swift, while still having to deliver C, C++, Objective-C and Objective-C++ stuff.

Or Google slowly adopting Rust, yet it still isn't officially supported on the NDK, or being the main language used on V8.

[tobias12345]

Which option? To write wrappers now instead of later?

I just see no way to be able to use current C++ code in a profiles world without wrappers or even a rewrite. For some code with decent semantics, a modern enough code base and clean APIs that wrapper might be just slapping a "compatible with profile FooBar" somewhere. On the other hand those are the APIs that are the easiest to wrap for other languages, too.

> As an example, while Microsoft slowly adopts Rust, it keeps putting out best practices and improved tooling, they aren't going to rewrite the whole Windows, XBox and Azure C++ code into Rust for the next couple of decades, or how long they would still matter on the market place.

So they are making the jump away from C++ now, wrapping their existing code to reuse it from safer languages. Smart :-)

[pjmlp]

Use Rust, not an option in many industrial use cases.

[tobias12345]

There is more out there than C++ and Rust, but yes, if you are stuck with C++, then you have no option but to wait for a couple of years and start to rewrite wehn C++ is ready.

I seriously hope all your competition is in a similar situation or it might become harder and harder for you to meet requirements going forward. The push towards memory-safe languages is out there.