[dureuill]

> You are actually just arguing for the sake of arguing here.

I'm very much not doing that.

I'm just really tired of reading claims that "C++ is actually safe if you follow these very very simple rules", and then the "simple rules" are either terrible for performance, not actually leading to memory safe code (often by ignoring facts of life like the practices of the standard library, iterator and reference invalidation, or the existence of multithreaded programming), or impossible to reliably follow in an actual codebase. Often all three of these, too.

I mean the most complete version of "just follow rules" is embodied by the C++ core guidelines[1], a 20k lines document of about 116k words, so I think we can drop the "very very simple" qualifier at this point. Many of these rules among the more important are not currently machine-enforceable, like for instance the rules around thread safety.

Meanwhile, the rules for Rust are:

1. Don't use `unsafe`

2. there is no rule #2

*That* is a very very simple rule. If you don't use unsafe, any memory safety issue you would have is not your responsibility, it is the compiler's or your dependency's. It is a radical departure from C++'s "blame the users" stance.

That stance is imposed by the fact that C++ simply doesn't have the tools, at the language level, to provide memory safety. It lacks:

- a borrow checker

- lifetime annotations

- Mutable XOR shared semantics

- the `Send`/`Sync` markers for thread-safety.

Barring the addition of each one of these ingredients, we're not going to see zero-overhead, parallel, memory-safe C++. Adding these is pretty much as big of a change to existing code as switching to Rust, at this point.

> Use the abstractions within the rules and you won't get issues, use compiler flags and analyzers on CI and you don't even need to remember the rules.

I want to see the abstractions, compiler flags and analyzers that will *reliably* find:

- use-after-free issues

- rarely occurring data races in multithreaded code

Use C++ if you want to, but please don't pretend that it is memory safe if following a set of simple rules. That is plain incorrect.

[1]: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

[jpc0]

A significant portion of the core guidelines you don't need to read and are already dealt with in static analysers. As I said, you don't need to know the rules, enable an analyser and you get the exact same experience as rust, your code won't pass the build step.

And am I going to tell the family of the dead person at a funeral my code failed but it's not my fault, the compiler has a bug and I couldn't confirm that myself? And don't pull the "the code is open source you can look at it" crap, I invite you to go and reason about any part of the rust compilers codebase.

In C++ I have multiple compilers all targeting the exact same standard and if in one of them my code is broken I need to explain that, I also have multiple analysers for the same thing.

Also haven't had a single segfault nor memory corruption not index error because I run santizers and analysets on CI, so all those things get caught in build or in testing just like in rust.

Is it as simple as rust, no, and I've already said that but I get the same safety guarantees and I am in control of the code. There isn't some subset of things I cannot do because the languages' built in analysers determines it too expensive to statically analyse that and they don't trust me as a developer to actually write tests and validate all the preconditions I have documented.