13 ms·
Safe C++ proposal is not being continued
- seanbax 1y agoI 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 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.
- x0nr8 1y agoUnrelated but are you back at the Big Green? Curious about what they have you working on.
- tobias12345 1y agoSean 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.
- motorest 1y agoFrom the article: > 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.
- InCom-0 1y agoJust 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.
- LorenDB 1y agoThe 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.
- coffeeaddict1 1y agoThe safety story with Profiles is rather basic (almost laughable honestly) and hardly any improvement over what was already achievable with compiler flags and clang-tidy.
- TimorousBestie 1y agoC++ is working towards safety with the same enthusiasm with which I tackle AI-generated merge requests.
- loeg 1y agoSeems clear enough to me. The "Safe C++" proposal is not being continued. Profiles is not what was proposed in "Safe C++."
- pessimizer 1y agoThe quotes you have added are not in the title, and they would of course make it less ambiguous.
- TinkersW 1y agoHardware level safety will arrive first(see Apple support for Memory Integrity Enforcement ), not as fool proof as SafeC++/Rust but no need to change code...
- pjmlp 1y agoIt has been already here since 2015 on Solaris SPARC.
- strus 1y agoI don’t think anyone is surprised.
- quotemstr 1y agoOkay, 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.
- int_19h 1y agoThe reason why WHATWG was able to take over HTML like that is because all the people & companies that were actually making the browsers were onboard. With C++, my impression is that most implementers simply aren't interested. And, conversely, most people who might be interested enough to roll a new implementation have already moved to Rust and make better use of their time improving that.
- quotemstr 1y agoYou're right, but dammit, I wish you weren't. A world in which we can evolve existing large C++ codebases gradually towards safety instead of having to RRiR is a better world. There are lots of cool innovations C++ made that will just disappear from the Earth, forever, if C++ can't be made memory safe in the same sense Rust is. I mean, Rust doesn't even support template specialization. I don't think it's too late for someone to fork both C++ and Clang and make something that's actually a good synthesis of the old and the new. But yeah, the most likely future is one on which C++ goes the way of Fortran (which still gets regular updates, however irrelevant) and the energy goes into Rust. But I like to rage, rage, against the dying of the type based metaprogramming.
- tiberius_p 1y agoI'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?
- quotemstr 1y agoThat's what the "Profiles" feature is. The problem is that any nontrivial real world program in a non-GC language needs non-owning reference types to perform well, and you can't express the rules for safe use of non-owning references without augmenting the language. People have tried. You need something more sophisticated than using smart pointers for everything. In the limit, smart pointers for everything is just called "Python". What infuriates me about the C++ safety situation is that C++ is by and large a better, more expressive language than Rust is, particularly with respect to compile time type level metaprogramming. And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety. Because of the C++ standards committee's misfeasance, I'm going to have to live in a world where I don't get to use some of my favorite programming techniques.
- Yoric 1y ago> In the limit, smart pointers for everything is just called "Python". To be more precise, it's old Python. Recent versions of Python use a gc. > And I am being walked hands handcuffed behind my back, alongside everyone else, into the Rust world with its comparatively anemic proc macro shit because the C++ committee can't be bothered to care about memory safety. Out of curiosity (as someone working on static analysis), what properties would you like your compiler to check?
- ranger_danger 1y agoTo be even more precise: > Reference counting is the primary mechanism of garbage collection, however, it doesn’t work when the references have cycles between them and for handling such cases it employs the GC.
- tialaramex 1y agoI 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.
- topspin 1y ago> I am actually much more pessimistic about Profiles than Simone. Likewise. Apparently Stroustrup wrote his first Profiles paper two years before HN existed. That's an incubation period long enough to wonder about its value, for multiple values of "value."
- phatskat 1y agoI’m very disconnected from the C/++ world, so when I was reading about profiles in another comment here (the one about the committee essentially saying “Safe C++ is off the table”), profiles sounded like something that was in an early phase of planning and implementation. Then the linked Reddit thread mentioned them being a thing in 2015 and I thought “oof they’ve been on profiles for a minute and it’s this underdeveloped?” and now your comment - yikes! There was a time when I was learning programming where my options were what the library offered: books on C/++, Java, obscure X extensions, Assembly, and BASIC. I quickly found that C just didn’t “click” for me and the JRE/JDK was a real pain to work with on a slow internet connection and no guidance. The only thing that’s made me want to go back to trying systems programming is the existence of Rust - I like the concept of the borrow checker and the added safety in general, and the community I’ve seen online seems a lot more inviting and friendly than I ever felt trying to find C++ resources. All that said, the conversation around core safety in C++ and the community’s reaction to “workarounds” (like offloading functionality to Rust) makes me want to just never step back in to that particular world. There’s no appeal I can see about loading a footgun and putting on a blindfold unless you need to work in that world.
- 1y ago
- flykespice 1y agoC++ 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.
- winrid 1y agoC+++ :)
- ImTotallyVegan 1y agoC+-
- usamoi 1y agoThey 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.
- steveklabnik 1y agoThe principles document that was accepted feels very targeted at Safe C++ specifically. It’s fair to say they rejected it.
- MattDamonSpace 1y agoI work on a Swift/iOS app that wraps a C++ library 90+% of our crashes are from hard-to-diagnose cpp crashes. Our engineers are smart and hardworking but they throw their hands up at this. Please tell me my options aren’t limited to “please be better at programming”…?
- fulafel 1y agoDoes iOS let you run it in another process? That's a common technique to isolate your app from crashy 3rd party components. This can work if you don't pass it untrusted data. If there's untrusted data coming in and you give it to a crashy c++ component, you're just asking to be pwned. For containing legacy C++ codebases https://fil-c.org/ https://fil-c.org/ looks promising as well, and could fit the bill better if the data was user supplied. It's been discussed on HN many times, most recently here https://news.ycombinator.com/item?id=45133938 https://news.ycombinator.com/item?id=45133938 .. but currently doesn't support iOS.
- krater23 1y agoSorry, but yes, when your app crashes there could be two issues. The C++ library that you use is shit, or your engineers don't understand the underlying concept of allocating/deallocating things because for Swift they had never to learn them. With Rust the code just wouldn't compile at all, that the only difference.
- 1y ago
- the_black_hand 1y ago"If you want to write like Rust, just write Rust". Exactly. No reason not to. RIP cpp
- heresie-dabord 1y ago> "If you want to write like Rust, just write Rust". And if you want to write like D...
- westurner 1y agoRust then? From "The state of Rust trying to catch up with Ada [video]" https://news.ycombinator.com/item?id=43007013 https://news.ycombinator.com/item?id=43007013 : > [awesome-safety-critical] > rustfoundation/safety-critical-rust-consortium: https://github.com/rustfoundation/safety-critical-rust-consortium https://github.com/rustfoundation/safety-critical-rust-conso... rust-lang/fls: https://github.com/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 https://safecpp.org/draft.html
- lallysingh 1y agoCall 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?
- burakemir 1y agoThere 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. I have a little post that explains this using a few more words, if interested: https://burakemir.ch/post/memory-safety-the-missing-def/ https://burakemir.ch/post/memory-safety-the-missing-def/
- MForster 1y agoYou are talking about spatial safety. There are a few other types of memory safety: - temporal safety (e.g. no use after free) - initialization safety (no read of initialized memory) - thread safety (no data races) - type safety (accessing memory with the correct type)
- Panzerschrek 1y agoThe 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.
- seanbax 1y agoWhich ideas aren't strictly necessary to achieve safety in C++?
- Panzerschrek 1y agoPorting Rust enums and pattern matching isn't necessary (C++ already has std::variant). Lifetime parameters aren't necessary, lifetime contracts may be implemented in a different and much easier way. This may be expressed in form of a function attribute, which may be calculated via constexpr code. Special operators for borrowing just add more complexity. C++ already achieves same behavior by normal references (which may be mutable and non-mutable). Introducing immutability by default isn't strictly necessary for achieving safety. C++ developers are already mostly fine writing "const" almost everywhere.
- purplesyringa 1y ago> Lifetime parameters aren't necessary, lifetime contracts may be implemented in a different and much easier way. This may be expressed in form of a function attribute, which may be calculated via constexpr code. Wouldn't that just be slightly different syntax for the same idea? If you want to represent relationships like "the pointer in the field Struct::field_name within this argument is linked with the lifetime of the returned pointer" and you want them to be reusable across functions and contexts, isn't the most obvious way to write that a variant of struct Struct<'a> { char *'a field_name; }; char *'a f<'a>(Struct<'a>& struct); ?
- Panzerschrek 1y ago
- nechuchelo 1y agoI 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.
- juliangmp 1y agoI'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".
- vdfs 1y agoNeither will those projects use Safe C++
- Davidbrcz 1y agoYou can't convince me that 'safe c++' is not an oxymoron.