6 ms·

Safe C++

101 points by matt_d 2y ago

xiphias2 2y 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++.
netbsdusers 2y 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 2y 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-one-most-loved-programming.html 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 https://en.m.wikipedia.org/wiki/Apollo_Guidance_Computer
  - netbsdusers 2y 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/rust.texi 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-garbage-collection-from-the-rust-language.html 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 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 2y 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 2y 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"
yosefk 2y 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
- _lvbh 2y ago
  Do you see this realistically getting implemented?
  - steveklabnik 2y ago
    It is implemented in Circle already.
    - _lvbh 2y ago
      Oh wow I just took a look and it’s really impressive. Adding more complexity to C++ does make it just that much more difficult for beginners though
- edward28 2y ago
  It just looks like an ugly version of rust.
  - lenkite 2y ago
    Considering that Rust is an ugly language to read, it shouldn't make much difference.
  - ramon156 2y ago
    I love Rust but it didn't invent memory safety. This is a weird take
    - fithisux 2y ago
      Jean-Yves Girard
    - steveklabnik 2y ago
fuhsnn 2y 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.
- fithisux 2y ago
  Or the "other" languages Zig/Nim/D/Go (or even scripting languages R, Julia, *Lisp, TCL, Ruby, Scilab, Python ...) at last.
  - deleted 2y ago
    [deleted]
  - cashsterling 2y ago
    Also add Ada... we tend to forget Ada but it was doing what Rust is before it was cool.
    - thesuperbigfrog 2y ago
      >> we tend to forget Ada but it was doing what Rust is before it was cool. As someone who has done a fair bit of Rust and Ada programming, this is not quite accurate an overlooks the innovations of Rust and the strengths of Ada: In my opinion, Rust's biggest innovations are 1) borrow checking and "mutation XOR sharing" built into the language, effectively removing the need for manual memory management or garbage collection, 2) Async/Await in a low-level systems language, and 3) Superb tooling via cargo, clippy, built-in unit tests, and the crates ecosystem (in a systems programming language!) Rust may not have been the first with these features, but it did make them popular together in a way that works amazingly well. Ada's strengths are its 1) powerful type system (custom integer types, use of any enumerated type as an index, etc.), 2) perfect fit for embedded programming with representation clauses, the real-time systems annex, and the high integrity systems annex, and 3) built-in Design-by-Contract preconditions, postconditions, and invariants. Compared to Rust, Ada feels a bit clunky and the tooling varies greatly from one Ada implementation to another. However, for some work, Ada is the only choice because Rust does not have sufficently qualified toolchains yet. (Hopefully soon . . .) Both languages have great foreign function interfaces and are relatively easy to use with C compared to some other programming languages. But Ada is not "Rust but from the 1980s" anymore than Rust is "like Ada, but newer". Having done a fair bit of C programming in the past, today I would always choose Rust over C or C++ when given the choice. But when working with really big C++ codebases, you don't always get to choose so something like Safe C++ is good to help add Rust-like features to C++ code.
fithisux 2y ago
"Over the past two years," suddenly they remembered to make it safe!!! Seems others used their backdoors.
sigmaprimus 2y 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 2y 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 2y ago
I believe this is Circle C++ with a new domain name. See also: https://news.ycombinator.com/item?id=40553709 https://news.ycombinator.com/item?id=40553709 - Circle C++ with memory safety (2024-06-02) https://news.ycombinator.com/item?id=23086227 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 https://news.ycombinator.com/item?id=19224176 - Circle: The C++ Automation Language (2019-02-22)
- pjmlp 2y ago
  Circle is the work that feeds into this WG21 paper proposal, so naturally looks like Circle.
captainmuon 2y 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.
- twoodfin 2y 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.
- steveklabnik 2y 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-array-while-iterating https://stackoverflow.com/questions/12232788/adding-to-an-ar...
Animats 2y 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++.
- gpderetta 2y 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 2y 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.
    - gpderetta 2y ago
      I think this one is the first one that actually got a document number assigned though, right? Although still a draft number and it is far from actually having wordings.
- pjmlp 2y 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 2y 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 2y 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.
- klik99 2y 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.
- jampekka 2y 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 2y ago
  I agree, with the slightly altered advice: just use Swift instead
jedisct1 2y 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.

101 points by matt_d 2y 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++.

netbsdusers 2y 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 2y 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-one-most-loved-programming.html 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 https://en.m.wikipedia.org/wiki/Apollo_Guidance_Computer
- netbsdusers 2y 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/rust.texi 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-garbage-collection-from-the-rust-language.html 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 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 2y 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 2y 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"

yosefk 2y 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

_lvbh 2y ago
Do you see this realistically getting implemented?
- steveklabnik 2y ago
  It is implemented in Circle already.
  - _lvbh 2y ago
    Oh wow I just took a look and it’s really impressive. Adding more complexity to C++ does make it just that much more difficult for beginners though
edward28 2y ago
It just looks like an ugly version of rust.
- lenkite 2y ago
  Considering that Rust is an ugly language to read, it shouldn't make much difference.
- ramon156 2y ago
  I love Rust but it didn't invent memory safety. This is a weird take
  - fithisux 2y ago
    Jean-Yves Girard
  - steveklabnik 2y ago

fuhsnn 2y 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.

fithisux 2y ago
Or the "other" languages Zig/Nim/D/Go (or even scripting languages R, Julia, *Lisp, TCL, Ruby, Scilab, Python ...) at last.
- deleted 2y ago
  [deleted]
- cashsterling 2y ago
  Also add Ada... we tend to forget Ada but it was doing what Rust is before it was cool.
  - thesuperbigfrog 2y ago
    >> we tend to forget Ada but it was doing what Rust is before it was cool. As someone who has done a fair bit of Rust and Ada programming, this is not quite accurate an overlooks the innovations of Rust and the strengths of Ada: In my opinion, Rust's biggest innovations are 1) borrow checking and "mutation XOR sharing" built into the language, effectively removing the need for manual memory management or garbage collection, 2) Async/Await in a low-level systems language, and 3) Superb tooling via cargo, clippy, built-in unit tests, and the crates ecosystem (in a systems programming language!) Rust may not have been the first with these features, but it did make them popular together in a way that works amazingly well. Ada's strengths are its 1) powerful type system (custom integer types, use of any enumerated type as an index, etc.), 2) perfect fit for embedded programming with representation clauses, the real-time systems annex, and the high integrity systems annex, and 3) built-in Design-by-Contract preconditions, postconditions, and invariants. Compared to Rust, Ada feels a bit clunky and the tooling varies greatly from one Ada implementation to another. However, for some work, Ada is the only choice because Rust does not have sufficently qualified toolchains yet. (Hopefully soon . . .) Both languages have great foreign function interfaces and are relatively easy to use with C compared to some other programming languages. But Ada is not "Rust but from the 1980s" anymore than Rust is "like Ada, but newer". Having done a fair bit of C programming in the past, today I would always choose Rust over C or C++ when given the choice. But when working with really big C++ codebases, you don't always get to choose so something like Safe C++ is good to help add Rust-like features to C++ code.

fithisux 2y ago

"Over the past two years," suddenly they remembered to make it safe!!! Seems others used their backdoors.

sigmaprimus 2y 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 2y 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 2y ago

I believe this is Circle C++ with a new domain name. See also: https://news.ycombinator.com/item?id=40553709 https://news.ycombinator.com/item?id=40553709 - Circle C++ with memory safety (2024-06-02) https://news.ycombinator.com/item?id=23086227 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 https://news.ycombinator.com/item?id=19224176 - Circle: The C++ Automation Language (2019-02-22)

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

captainmuon 2y 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.

twoodfin 2y 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.
steveklabnik 2y 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-array-while-iterating https://stackoverflow.com/questions/12232788/adding-to-an-ar...

Animats 2y 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++.

gpderetta 2y 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 2y 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.
  - gpderetta 2y ago
    I think this one is the first one that actually got a document number assigned though, right? Although still a draft number and it is far from actually having wordings.
pjmlp 2y 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 2y 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 2y 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.

klik99 2y 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.
jampekka 2y 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 2y ago
I agree, with the slightly altered advice: just use Swift instead

jedisct1 2y 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.