I’ve done a bit of C++ coding in my time. The feature list of the language is so long at this point that it is pretty much impossible for anyone new to learn C++ and grok the design decisions anymore. I don’t know if this is a good thing or not to keep adding and extending or whether C++ should sail into the sunset like Fortran and others before it.

C++'s feature set follows the same rules as the Borg.

On one hand, I’m pleased that C++ is answering the call for what I’ll call “safety as default”, since as The Register and everyone else since pointed out, if safety constructs are “bolted on” like an afterthought, then of course it’s not going to have very high adoption. Contrast this to Rust and its “unsafe” keyword that marks all the places where the minimum safety of the language might not hold.

On the other hand, while this Safe C++ proposal adopts a similar notion of an “unsafe” context, it also adds a “safe” keyword, to specify that a function will conform to compile-time safety checks. But as the proposal readily admits:

Rust’s functions are safe by default. C++’s are unsafe by default.

While the proposal will surely continue to evolve before being implemented, I forsee a similar situation as in C where code that lacked initial const-correctness will struggle to work with newer code and libraries. In this case, it would be the “unsafe” keyword that proliferates everywhere just to call older, unsafe code from newer, safe callers.

Rust has the advantage that there isn’t much/any legacy Rust to upkeep, and that means the volume of unsafe code in Rust proframs is minimal, making them safer overall today. But for Safe C++ code, there’s going to be a lot of unsafe legacy C++ code and that reduces the safety benefit for programs overall, for the time being

Even as this proposal progresses, the question of whether to start rewriting some code anew in Rust remains relevant. But this is still exciting as a new option to raise the bar in memory safety in C++.

Rust: The Phantom Menace

I’m a bit skeptical that a borrow checker in C++ can be as powerful as in rust, since C++ doesn’t have lifetime annotations. Without lifetime annotations, you have to do a whole program analysis to get the equivalent checks which isn’t even possible if you’re e.g. loading dynamic libraries, and prohibitively slow otherwise. Without that you can only really do local analysis which is of course good but not that powerful.

Lifetime annotations in the type system is the right call, since it allows library authors to impose invariants related to ownership on their consumers. I doubt C++ will add it to their typesystem though.

Oh yes! Let’s keep adding more bloat to ultra complex language C++ surely it will fix everything !

Is this going to be re-posted every month?

Anyway, I’ve come to know since then that the proposal was not a part of a damage control campaign, but rather a single person’s attempt at proposing a theoretical real solution. He misguidedly thought that there was actually an interest in some real solutions. There wasn’t, and there isn’t.

The empire are continuing with the strategy of scamming people into believing that they will produce, at some unspecified point, complete magical mushrooms guidelines and real specified and implemented profiles.

The proposal is destined to become perma-vaporware. The dreamy guidelines are going to be perma-WIP, the magical profiles are going to be perma-vapordocs (as in they will never actually exist, not even in theoretical form), and the bureaucracy checks will continue to be cashed.

So not only there was no concrete strike back, it wasn’t even the empire that did it.

The big downside is that, for backwards compatibility, the default must still be unsafe code. Ideally this could be toggled with a compiler flag, rather than having to wrap most code in “safe” blocks (like rust, but backwards).

One potential upside that people don’t seem to be discussing is that the safe subset could also be the place to finally start cutting down the bloat of C++. We could encourage most developers to write exclusively in the safe subset, and aim to make that the “much smaller and cleaner language” trying to get out of C++.

That’s a wild screenshot.

Google started work on Carbon due to the difficulty of getting the C++ standards committee to accept any real, fundamental changes to the language. If Google, a grandmaster at manipulating standards committees, couldn’t get something passed, I don’t foresee this proposal getting anywhere.

The inherent problem with this kind of solution is that if you don’t break backwards compatibility, you don’t get rid off all the insecure code.

And if you do break backwards compatibility, there’s not much reason to stick to C++ rather than going for Rust with its established ecosystem…

struct CxxThingamabob { ... }

#[derive(Serialize, Deserialize)]
#[serde(transparent)]
struct SerializableCxxThingamabob(CxxThingamabob);