Not a fan of where this is going. Just use Rust instead. All this is doing is making c++ even more unmanageable. When developers are pressed for time they will revert to what they are used to and know. What you get in the end is a mess of code with different ideas at different parts of the system because they are developed at different times by different people. Or you are going to put down very strict guidelines and redevelop everything according to these guidelines. Then you are back to rather use Rust instead. The guidelines is built in the Rust language.

I believe this is Circle C++ with a new domain name. See also:

https://news.ycombinator.com/item?id=40553709 - Circle C++ with memory safety (2024-06-02)

https://news.ycombinator.com/item?id=23086227 - Circle – A C++ compiler with compile-time imperative metaprogramming (2020-05-05)

https://news.ycombinator.com/item?id=19224176 - Circle: The C++ Automation Language (2019-02-22)

I think this is really interesting work, and as others have said it is a herculean undertaking by Sean Baxter to try to rework C++.

That being said, I'm not sure I like the direction. C++ is already more than complicated enough. And I'm not a big fan of the "mut XOR shared" principle taken from Rust, because I don't really have the problem of accidentially mutating something that was shared. Well, maybe I don't get the point because I'm a "Blub programmer" :-).

The example that is presented here and in many introductory articles about Rust is mutating a vector while iterating it. But why can't we just have a vector type that tolerates that and does something well-defined? What if we actually want to modify the list while iterating, because we are filtering the list for example?

I think one forward for C++ would be to define a safe subset. Deprecate a lot of features when using this subset, and make sure with a linter that they are not used. Hide raw pointers as much as possible. Ban UB as much as possible or give it some safe default. If you need some "UB" for optimisations (that is, you need the compiler to be able to make certain assumptions), then I want the compiler to tell me:

> "Could optimize further if we assume `a` and `b` are not aliasing, please add annotations to allow optimisation or to suppress this message".

Finally we need a new boring standard lib, closer to Java and Qt than the gnarlyness of the STL. The spirit should be like that of Java or Go, boring, efficient enough, productive for the average developer, not to many ways to shoot yourself in the foot.

It's nice, but it's about the tenth attempt to make C/C++ safe. I've been down that road myself. To succeed, this needs some major organization, something the size of Microsoft, Google, or the U.S. Government, pushing it hard. Someone has to fund retrofits of important trusted code, such as OpenSSL.

When you're all done, it will be at least as crufty as C++.

> Exceptions are a poor way to signal out-of-memory states. If containers panicked on out-of-memory, we’d enormously reduce the cleanup paths in most functions.

What exactly is the difference between a panic and an exception? According to everything I've been able to read about Rust's panic mechanism, it's just that "panics shouldn't be used for normal errors", which is just a prescription on the normative use of the construct. A pretended difference. Can anyone clarify whether there actually is a real difference? Or when "Panic" is said here, does the author mean something that cannot be meaningfully recovered from? That would be a change most inappropriate!

One of the most prominent birthmarks that Rust was stamped with when it was born as an apps (not systems) language was its standard library being designed without regard to the possibility of reacting to out-of-memory conditions by anything other than aborting. Now that it's trying to pivot from solely an apps language to a systems language for some time, there seems to be work underway to correct that deficiency.

C++ for its part is not burdened with that mistake. There is remarkable attention paid in the STL to the possibility of an out-of-memory condition and allowing a complete recovery from the same. This is a useful feature that systems software often requires.

why isn't this getting traction? it's a pretty big deal. it's the most safe of proposed C++ safety extensions by far

Coming into this thread late, but one thing I wished to see in this discussion is the mention of the truism that I first read here:

Successor languages must have full (or at least broad) compatibility with the language they're replacing. Look at C++ itself; it started as a C transpiler, and has some of the longest running C compat of any extant language. Same goes for TypeScript, which is fairly widely used in production, I think even moreseo than Rust, for all the hype it generates,

This is an interesting proposal for that reason alone; it would allow a slow and deliberate conversion process, but also would allow safety standards to include language like "no unsafe blocks allowed unless proven safe"

Aside from "making C++ safe", the design looks like a good opportunity to have better Rust interop, if a standardized FFI with clear object lifetime semantics can be established between C++ and Rust, it's a win for everyone.

This looks like a huge improvement from the original Circle language that didn't look like C++ at all. I love it and would love to have it in C++.

Even without all the safety parts, this is amazing:

> The new choice type is a type safe discriminated union. It’s equivalent to Rust’s enum type.

"safety" != "memory safety"

A formally proven implementation could be called "safe".

But code written with checked arrays and without explicit pointers isn't magically safe, and promoting a language or a cookbook as something that makes applications "safe" is just abusive and annoying marketing.

Considering my city Is still running 16 bit Operating systems Off floppy drives For some of the infrastructure... Well I don't know, Maybe that makes it more secure? I have no idea How These systems haven't been hit yet. Or maybe they have?

"Over the past two years,"

suddenly they remembered to make it safe!!!

Seems others used their backdoors.