The title has potential to be a bit misleading, because as the article says, while Sean Baxter's proposal is not being continued, the committee is working on the Profiles proposal, which still will enable some level of safety. So C++ is still working towards safety, just not the Safe C++ safety.
Okay, so treat the C++ standards committee the same way the HTML5 people treated W3C. If they insist on making themselves irrelevant, let them.
Profiles cannot achieve the same level of safety as Rust and it's obvious to anyone who breathes. Profiles just delete stuff from the language. Without lifetimes reified as types you can't express semantics with precision enough to check them. The moment string_view appears, you're horked.
Okay, so you ban all uncounted reference types too. Now what you're left with isn't shit Rust but instead shit Swift, one that combines the performance of a turtle with the ergonomics of a porcupine.
There's no value in making things a little bit safer here and there. The purpose of a type system is to embed proofs about invariants. If your system doesn't actually prove the the invariant, you can't rely on it and you've made is a shitty linter.
Continue the safe C++ work outside the context of the C++ standards committee. Its members, if you ignore their words and focus on the behaviors, would rather see the language become irrelevant than change decades old practices. Typical iron law of bureaucracy territory.
I'm not up to date with the latest developments in C++ but would't it be straightforward to do something like "#pragma pointer_safety strong" which would force the compiler to only accept the use of smart pointers or something along those lines. Was anything like this proposed so far?
I am actually much more pessimistic about Profiles than Simone.
Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon.
The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen minute bagpipe dirge your lead single it doesn't really matter whether you use the colored vinyl.
Rust has safety culture? Not in the wild, a lot of coders seem to think its cool to use unsafe to get an extra hairpin of performance at the cost of safety
C++ will never be safe as long as its C root persists, it doesn't matters how much freatures you add on top of C++ to make writing safe programs more convenient.
You need to take off the "inherently unsafe" C root from C++, but it wouldn't be called C++ anymore by that point.
They are not rejecting Safe C++; they are rejecting memory safety. Majority of them believes that memory safety is just hype, and minority of them knows it's a problem, but doesn't want to restrict themselves about coding. If code runs, it is fine. If it does not, coder running is fine too.
Call me stupid for asking, but what is "safe" here? I get the length-checked buffer copies and accesses, is there anything else? Less allowed type conversions?
There is an old definition of language safety which means "no untrapped execution errors". It is not the only way to define safety, but it is a good way that you can adapt to various kinds of x-safety, such as memory safety.
The mentioned proposal isn't really that great. It basically tries to make C++ to Rust by blindly copying many its ideas. Many of them aren't strictly necessary to achieve safety in C++. There are different proposals for safety, which are way smaller and simpler than this one.
I do want C++ to be a safer language, but I don't think inheriting the Rust safety model is the way to go. It is in a way revolutionary but has major downsides like inability to deal with cyclic data structures without clumpsy workarounds.
I don't want to play with a plastic sword, just put it in a sheath.
I'm unsure a bout the profiles. If they add restrictions and need to be enabled as a compiler flag, no legacy project I'll use them since they'd probably get like 4 errors and say "oh this options breaks my code, but the code has been running for years so its fine".
I would have implemented profiles if profiles had a chance of working. But they will not ever work. I present many examples of why they fail here:
https://www.circle-lang.org/draft-profiles.html
People who say Profiles are a path forward, please address any of the points in this document.
Sean Baxter stated that he is not working on Safe C++ anymore, so that proposal is dead.
But is somebody still working on safety profiles? I have not noticed and profiles related paper seeing updates since Hagenberg. Herb just wrote in his trip report "Profiles papers received a lot of discussion time in EWG (language evolution working group) and feedback to improve consensus,", which leaves any interpretation open.
> Profiles seem less radical and more adoptable, a safer-by-default C++ without forcing the Rust model that aims to tackle the most common C++ pitfalls.
Just use sanitizers properly. You are done. Everyone doing anything half-professional with C++ has been doing that for years already. And no you don't have to run sanitizers in production.
That being said: It is inconvenient and it is stacking yet another set of tools and workflow that you have to integrate into your development practice, which is not so nice.
Also, profiles are a better idea anyway.
Also, I wish people would stop calling things 'safe'. Ain't nothing 'safe'. There are only various degrees of safety.
23 comments
[ 3.5 ms ] story [ 47.0 ms ] threadProfiles cannot achieve the same level of safety as Rust and it's obvious to anyone who breathes. Profiles just delete stuff from the language. Without lifetimes reified as types you can't express semantics with precision enough to check them. The moment string_view appears, you're horked.
Okay, so you ban all uncounted reference types too. Now what you're left with isn't shit Rust but instead shit Swift, one that combines the performance of a turtle with the ergonomics of a porcupine.
There's no value in making things a little bit safer here and there. The purpose of a type system is to embed proofs about invariants. If your system doesn't actually prove the the invariant, you can't rely on it and you've made is a shitty linter.
Continue the safe C++ work outside the context of the C++ standards committee. Its members, if you ignore their words and focus on the behaviors, would rather see the language become irrelevant than change decades old practices. Typical iron law of bureaucracy territory.
Regardless of the technology the big thing Rust has that C++ does not is safety culture, and that's dominant here. You could also see at the 2024 "Fireside chat" at CppCon that this isn't likely to change any time soon.
The profiles technology isn't very good. But that's insignificant next to the culture problem, once you decided to make the fifteen minute bagpipe dirge your lead single it doesn't really matter whether you use the colored vinyl.
You need to take off the "inherently unsafe" C root from C++, but it wouldn't be called C++ anymore by that point.
From "The state of Rust trying to catch up with Ada [video]" https://news.ycombinator.com/item?id=43007013 :
> [awesome-safety-critical]
> rustfoundation/safety-critical-rust-consortium: https://github.com/rustfoundation/safety-critical-rust-conso...
rust-lang/fls: https://github.com/rust-lang/fls
How does what FLS enables compare to these Safe C++ proposals?
Safe C++ draft: https://safecpp.org/draft.html
I have a little post that explains this using a few more words, if interested: https://burakemir.ch/post/memory-safety-the-missing-def/
I don't want to play with a plastic sword, just put it in a sheath.
People who say Profiles are a path forward, please address any of the points in this document.
But is somebody still working on safety profiles? I have not noticed and profiles related paper seeing updates since Hagenberg. Herb just wrote in his trip report "Profiles papers received a lot of discussion time in EWG (language evolution working group) and feedback to improve consensus,", which leaves any interpretation open.
> Profiles seem less radical and more adoptable, a safer-by-default C++ without forcing the Rust model that aims to tackle the most common C++ pitfalls.
That being said: It is inconvenient and it is stacking yet another set of tools and workflow that you have to integrate into your development practice, which is not so nice.
Also, profiles are a better idea anyway. Also, I wish people would stop calling things 'safe'. Ain't nothing 'safe'. There are only various degrees of safety.