Safe C++

https://safecpp.org/draft.html

by matt_d • 2 years ago

101 68 2 years ago

safecpp.org

yosefk• 2 years ago

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

_lvbh2• 2 years ago

Do you see this realistically getting implemented?

steveklabnik6• 2 years ago

It is implemented in Circle already.

edward28• 2 years ago

It just looks like an ugly version of rust.

ramon156• 2 years ago

I love Rust but it didn't invent memory safety. This is a weird take

foresto• 2 years ago

What do you think is beautiful about Rust, and why?

How do you think this proposal's equivalents are uglier?

kasabali• 2 years ago

Wait, there's a beautiful version?!

lenkite• 2 years ago

Considering that Rust is an ugly language to read, it shouldn't make much difference.

rurban• 2 years ago

If it would work, it would gain traction. Guaranteed.

missblit• 2 years ago

C++ is a very slow moving language. There are various rumblings about making it memory safe, but if we get a proper memory safe C++ it'll probably be in the '30s.

Night_Thastus• 2 years ago

Because C++ is big and old and everyone wants it to be something different. Functional programmers want it to be more functional, OOP developers want more object oriented, etc. And the syntax must look familiar. And everything must be backwards-compatible and all older legacy code needs to work fine. And it must have next-to-no runtime cost. Etc.

Making any changes to C++ is a slow process - as it is for any older and larger language.

Plus...I think memory safety is a pretty low priority area for C++, frankly. It's harder to shoehorn in at this point, C++ has never prioritized it over raw performance or flexibility.

pjmlp8• 2 years ago

Well, back in the pre C++98 days, compiler provided frameworks used to be safer by default than what got standardised.

jujube33• 2 years ago

There's no point. Rust can already be added incrementally in an existing C++ or C project. Like how Servo was in Firefox, or Rust in the Linux kernel.

jujube33• 2 years ago

Why was this downvoted? It's not just another generic "rewrite it in Rust" comment. I was making a specific point that incremental rewrites of existing C++ code are very possible in Rust. And that process would not be that different from rewriting the code in a "safe" dialect of C++.

If it makes you feel better you can rename the Rust language to "C++2.0" but the rewrite process itself will be the same in both cases. You keep expanding the amount of safe code you have within the codebase over time, one module at a time.

CuriousCosmic• 2 years ago

It's not that it isn't gaining traction. Rather it's just a massive, herculean undertaking that Sean and co have been working on in the background. Hell Sean only just a few months ago started posting demos on twitter of their C++ borrow checker proof of concept finally working in moderately non-trivial examples.

This isn't to say that their progress isn't going well. Rather they've been making incredible progress at a rate nobody really thought possible but this is just a truly Herculean effort.

Also this proposal is literally only 2 days old. The work has been in progress for years but this is to my knowledge the first time it has actually been proposed formally.

steveklabnik6• 2 years ago

This is correct. Sean has been working for something like two years implementing these ideas to make sure they’re feasible, and only recently turned to actual advocacy for them, now that the experiment appears successful.

fuhsnn• 2 years ago

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.

fithisux3• 2 years ago

Or the "other" languages

Zig/Nim/D/Go (or even scripting languages R, Julia, *Lisp, TCL, Ruby, Scilab, Python ...)

at last.

cashsterling• 2 years ago

Also add Ada... we tend to forget Ada but it was doing what Rust is before it was cool.

jedisct12• 2 years ago

Even PHP is a perfectly fine, memory-safe language.

fithisux3• 2 years ago

"Over the past two years,"

suddenly they remembered to make it safe!!!

Seems others used their backdoors.

sigmaprimus• 2 years ago

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?

amluto• 2 years ago

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.

omoikane• 2 years ago

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)

pjmlp8• 2 years ago

Circle is the work that feeds into this WG21 paper proposal, so naturally looks like Circle.

captainmuon• 2 years ago

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.

steveklabnik6• 2 years ago

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?

This adds overhead that’s not always desired. And sometimes, this ends up being a logic bug. There are languages where this produces a result instead of being UB, but it’s almost always shown off as a “can you believe this wacky behavior” because it’s not intuitive. From a random search I just did: https://stackoverflow.com/questions/12232788/adding-to-an-ar...

BiraIgnacio• 2 years ago

I absolutely love this, not just because of the safety aspect but because of how expressive it seems to be.

twoodfin• 2 years ago

“mut XOR shared” is less about protecting you from accidentally making inconsistent mutations, it’s more about the compiler’s need for a strong invariant against action-at-a-distance so it can manage to reason correctly about code in an isolated context.

Animats• 2 years ago

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++.

gpderetta3• 2 years ago

This is (or is going to be) a standard proposal I think, not just a dialect .

Of course it still need buy in from the major compilers to have a chance to be accepted.

favorited• 2 years ago

There are competing "safe C++ syntax" projects being advocated by people on WG21 (as well as some members who seem to be opposed to any memory or concurrency safety tools beyond guidelines and linters). It's going to be up an uphill fight for any of them to gain traction, but at least some people are putting in the effort.

pjmlp8• 2 years ago

On the other hand you will be able all the nice game engines, if this goes through. :)

OpenSSL is C and I hardly believe they will ever adopt anything else.

dwattttt• 2 years ago

Honestly, with the kind of changes and restrictions that you would end up needing, you'll end up with enough of a different language that you can't cleanly migrate a big existing codebase.

If a codebase wasn't designed with the intent of being able to prove validity & safety in the first place, trying to achieve it would be pretty rough. Not literally the same as trying to rewrite it in Rust, but the biggest problems would probably be comparable.

testrun• 2 years ago

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.

pjmlp8• 2 years ago

This is for corporations with 40 years of code in production, that hardly do greenfield development.

How will Rust look in 40 years, if it reaches thus far?

When will rustc stop depending on a C++ compiler construction framework?

holowoodman2• 2 years ago

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.

klik992• 2 years ago

Clearly, this is not for you.

I work in video games, most games use Unreal Engine, most existing toolsets and dependencies are built on C/C++, I have 17 years professional experience and nearly 30 years including hobbyist experience in C++. I often think I'd start new projects in Rust, but the last two large personal projects I started in C++, and one of them has been deployed in iOS, Android, Windows, Linux, Mac, WASM and RPi environments without much trouble. I haven't regretted that choice, even though I do really like Rust. In my contracting work, Rust just isn't an option. In my personal work, Rust is an option but since C++ has been getting better, I see less and less reason to use Rust.

But, you, please keep using Rust. It's a great language and I hope it someday eclipses C++. C++ was never designed as a cohesive language (Bjarne said exactly this in a talk I attended), it was designed as a grab bag of ideas, and I believe much of what's bad about C++ stems from that philosophy. Rust is built from the ground up with good ideas. But there's nothing wrong with improving C++ for those of us who it's really the best or only option.

EDIT: To be clear on this particular article, I agree it's not a great direction. But "just use Rust" is not helpful, and you may not have the problem this is trying to solve.

jampekka2• 2 years ago

When developers are pressed for time they will revert to what they are used to and know.

Is not being able to do this a great selling point for Rust? It's better to have nothing instead of code that may have a bug?

singularity2001• 2 years ago

I agree, with the slightly altered advice: just use Swift instead

jampekka2• 2 years ago

And ignore vast majority of computers? And suffer with Xcode?

jedisct12• 2 years ago

"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.

xiphias2• 2 years ago

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++.

netbsdusers2• 2 years ago

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.

hedora• 2 years ago

Rust was invented with an elevator firmware use cases in mind. The inventor happened to work for Mozilla, so it got traction in the lower level parts of Firefox next.

https://www.techspot.com/news/97654-how-broken-elevator-led-...

It has explicit error handling and no exceptions. All mission critical C++ software I’ve worked on uses --f-no-exception and panics then restarts on out of memory.

Hardware errors were way more common than OOMs for those embedded code bases, and we didn’t have the testing budget to fault inject OOMs everywhere in simulation.

I know other fields still try to use the “handle all error codes” approach, but “let it fail then restart” is simpler and (in my experience and theoretically) easier to get to be reliable, especially in distributed environments.

This isn’t a new idea. For instance, during the apollo 11 landing, the guidance computer was crash looping, but managed to recover the trajectory enough on each loop to get to the ground. Look at the section about 1201 and 1202 alarms here:

https://en.m.wikipedia.org/wiki/Apollo_Guidance_Computer

netbsdusers2• 2 years ago

Rust was invented with an elevator firmware use cases in mind. The inventor happened to work for Mozilla, so it got traction in the lower level parts of Firefox next.

TechSpot is referring (without attribution) to an interview the MIT Technology Review did with Hoare, and tacked on a claim that Rust was invented "to prevent issues such as his elevator breaking down" that isn't there in the source material. Elevator firmware is not systems software in any case, and the Rust manual Hoare authored states:

Rust's goals arise from the context of writing large programs that interact with the internet -- both servers and clients -- and are thus much more concerned with safety and concurrency than older generations of program.

https://github.com/graydon/rust-prehistory/blob/master/doc/r...

The language described there relies on a much larger runtime than Rust today does. It is no systems language. Later it even grew things like the @ garbage-collected pointers.

Those would eventually go away as it turned out that people writing apps don't want to think about memory at all (and are better served by using a real apps language) and Rust instead started embracing its potential as a systems language:

Although Rust didn't start out that way, one of the most interesting applications of Rust has been very low-level programming, even down to the level of kernels. The interest in this application of Rust was something of a surprise to us, but in hindsight it makes perfect sense. Low-level control over memory management isn't something that most applications software, especially on the server side, wants; most of that software has migrated over to languages like Java, Ruby, and JavaScript that trade control and performance for convenience by making memory management automatically, and dynamically, managed by the runtime. The remaining class of software, most of which is written in C and C++, is software that must manage memory manually in order to achieve some combination of performance, simplicity, and/or the ability to self-host. The prospect of using a new language for this class of software, which includes OS kernels, game engines, and browser engines among others, is what is fueling the growth of the nascent Rust community.

https://pcwalton.github.io/_posts/2013-06-02-removing-garbag...

For a lot of systems software, and I am thinking of system service managers ("init systems") in particular, failing and restarting is not viable. OOM conditions must be recoverable. Rust has recognised this and is trying to correct the course they went down in its early days of ignoring this, being unimportant for an apps language, but vital for a systems language.

One feature they have taken to is throwing panics on OOM conditions:

https://github.com/rust-lang/rust/issues/43596

These "panics" can unwind the stack and be caught with panic::catch_unwind, but with the proviso of only "sometimes". If you take that at face value, then it's not a very useful feature. The implication in the issue linked above however is that this could become a viable way to recover from OOM conditions. And the mechanism proposed there is indistinguishable from exceptions other than that it's insisted that it has nothing to do with exceptions and that you can't rely on it catching panics for you.

aw1621107• 2 years ago

What exactly is the difference between a panic and an exception?

By my understanding it's the difference between what you want to do and how you do it. Panicking is the what ("Something went wrong! Halt operation!"), exceptions are one of the hows (unwind). Aborting is the other one.

That's one of the reasons panics should not be used for normal errors - there's no general guarantee you can catch them. Granted, that's more of a restriction on library developers, since they don't control the panicking mode.

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.

At least by my impression OOM in the STL is generally handled via std::bad_alloc. While that's something at least, I'm not sure I'd call that "remarkable attention" on its own, especially since I don't think it's that uncommon for systems software to be compiled with -fno-exceptions. I'm not sure using alternative allocators would help in this case either, since I don't think the way APIs are defined allow you to surface allocation failures in any way other than exceptions (e.g., what happens on OOM during std::vector::push_back?).

To me, "remarkable attention" would be more akin to what Zig does with allocator parameters and surfacing allocation errors in the API.

ijustlovemath• 2 years ago

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"

Safe C++

Related Stories