A superset of C++, this is like infinity times infinity. And there is probably already something to help with memory safety, smart pointers and containers to name a few.
I think C++ needs to adopt some kind of safety mechanism, and Rust's borrow checker is really the only option for them, so it makes sense to me. I do agree that the syntax is pretty awful, and unlike Rust (where syntax can change with editions while maintaining forwards/backwards compatibility), C++ has no way of changing syntax once codified into the standard.
The proposal from this video comes from the circle project, which adds that idea of "feature on/off", so that you can enable and disable syntactic extensions with file granularity. The safe extension is one of that features, but the circle compiler have A TON OF syntactic extensions to C++. The leader of that project has tried to bring that idea to the standard committee through this proposal but I think the committee guys are far from convinced, and so I think this proposal is kinda dead already.
It won't stay that way anyway, that was an experimental syntax found in the Circle Compiler that Sean Baxter made before submitting this proposal, he didn't like p2996r5 (the C++26 reflection proposal) as it is but submitting for C++ he'll have no choice, the ^ will become the reflection operator, the ~as_pointer and ~as_length will not be viable and he'll have to rely on extending the reflection syntax for C++26 instead for that. So yeah the syntax isn't not only not set in stone, it is literally impossible for it to be like that. Personally I'd prefer if we had small keywords over the annoying ugly symbols anyway.
@@kerojey4442 You know what? By the time i made that comment and now that i read your reply, my opinion changed. Initially i only glanced a single rust program that was functional style, and that was pretty lean i thought maybe the problem with rust is the procedural style of writing, and functional style rust is okay; that is why i made the upper comment. Today, i glanced some other rust code, almost all of them functional style. Lets not talk about that . . .
Pregnancy safe condoms include:intercourse time safety, constant memory offset from sperm to egg, prohibit copying memory-your DNA to unsafe location. And lastly they guarantee that cpu-woman who "ran" your "code" won't file post execution lawsuit.
@@rezabani9904 it's impossibile that C won't survive for many reasons (linux, vulkan, etc). But i agree that zig is far better for 2024, i don't want to use it right now only because it is not stable yet
@@danielmilyutin9914 this could easily mitigated by add something like "Prefered default" for borrow checking to the compiler options. for those who like conventional idiomatic C++ can use legacy and dont even care about borrow checker.(safe and unsafe has no effect in this legacy mode)
@@danielmilyutin9914 the two security options can be used together, they are not a replacement for each other but offer complementary features. One of the features in the new proposal is the compiler makes compile time garuntees about the code inside the marked sections. So now its possible to mandate that certain parts of a project (on a compile unit by compile unit basis) must be written with all the security options enabled. For example areas that interact with the outside world to sanity check data handling. The point is expecting all developers to write idiomatic code just is not enough. They need a compiler flags that enforces the rules to do the secure thing.
Looking into the proposal, seems like it is authored by "The C++ Alliance". How legit is the alliance though? The official organization behind C++ is "Standard C++ Foundation". The Wikipedia page for C++ doesn't mention the alliance.
Месяц назад+2
At least it is opt in. When I need safety I just use Rust
Right now it seems that to convert an existing class from C++ to Safe C++ only requires rewriting about 95% of all the lines. And the lines that do not require rewriting are mostly "{" and "}" if you use Allman-8 formatting. I wish the syntax gets much nicer or it will be easier to use Rust and write a bridge between C++ and Rust in C.
Is it... really that hard to use smart pointers? Stick to unique pointers and bounds-checked containers for nearly everything and you'll be fine. Macro them too so they're shorter. This is the way I write all my C++ code nowadays anyway, and I've never had issues.
When people think smart pointers == safety, or thar rhis matter is just people wanting to use rust, you see how important the discussion is. I like C++, but it is true that without breaking changes tbe language will never catch up with real modern techniques and what toolig can do. New librart features cannot solve it, the language must enable things like safety, good straightforward meta programming and assist tooling functions
To my knowledge, borrow checker doesn't add any runtime performance penalties - borrowing is essentially a set of compile-time "rules" for managing memory.
@@cheesed_up Yeah the borrow checker is all compile time. However, the safe alternative standard library does include more runtime code to enforce invariants (bounds checking, etc.). As with Rust though, I suspect these checks are entirely worth it from a performance perspective. Most Rust developers don't even bother with `*_unchecked` versions of functions since the performance is close enough.
@@cheesed_up I guess the prohibition of undefined behaviour and the restriction of certain features could cause overhead in terms of optimizations that can't be applied any more. The borrow checker itself won't cause runtime overhead because it's just a set of compile-time checks, but the way user must change the code to make it borrow-checker-friendly could probably cause some performance impact.
As I understand it the penalty is no different to Rust but its optional. A progressive language enhancement. Yes there is a measurable runtime performance penalty (plenty of people have measured it in rust/cpp) but it isn't much. The greater penalty is the loss of algorithmic shortcuts. That is something C++ is traditionally used to achieve. The safe sections prevent many of the turbo assembler style optimizations relying on undefined-behaviour or non-portable constructs that are designed to squeeze every last programmer knows better than compiler cpu cycle out of performance. But its all optional, you get to choose, your employer gets to choose the regulatory body you need to comply with gets to choose. The best of all worlds for everyone and eventual end of discussion how do we make code safe from human error with the least expense. Now a compile flag, don't want to code in that environment that's ok there are plenty of other roles and languages to do something else in the field.
So it's a proposal where C++ gets another language embedded into it. You of course have to opt in to use it and it's probably going to be a billion new keywords and syntax. Sounds familiar doesn't it. The problem with C++ is the fact that it's too overbloated. If you need the safety features, you really don't have an option but use Rust.
@@geek2145 smart pointers dont guarantee memory safety. I hate it too but you MUST evolve as anything that falls under regulation is starting to be written in rust due to memory safety. there there is a proposal that ensures memory safety and allows for incremental adoption it must be looked at. either way dont use it if you dont want to, it isnt a must according to the proposal.
@@AA-qv7fb It can't be a must, because if it was it would break backwards compatibility, which is a requirement for c++. Let me be clear: I think safety by default is a great thing. If people or companies want that, then they shouldn't use c++. End of story. If you use a modern subset of c++, then memory errors will be extremely uncommon. The sanitizers provided by compilers can detect anything that slips between the cracks. The issue is that most devs do not do any of this. Most devs turn off compiler warnings that they find annoying. The issue isn't a lack of memory safety features in c++, there are more than enough. The issue is that developers don't use them. Because they don't care.
@@AA-qv7fb The issue of memory errors is primarily a cultural one. The benefit of safety-by-default is that the language enforces a certain perspective. You are required to care. You can't add that to c++.
The problem isn't that you can't write safe code, the problem (as I understand it) is that the compiler cannot verify that the code you wrote won't produce undefined behaviour. What I find incredible is the idea that compilers are even able to verify that code is safe at all
I am still a C++ noob, but I have made at least one fairly big c++ project on my own. It was fairly easy, and I encountered very few issues. I am very curious about what all the "unsafe" talk even means? I only know modern c++, and have never used a raw pointer
Reference counting doesn't make pointers safe. I think cuktish behavior is when people proclaim something based on their beliefs about something without actually understanding it
The biggest reason I dont use Rust is because of the ugly syntax. Call me stupid, but its just not fun. I was thrilled to hear that C++ is considering implementing safe code with a borrow checker. I was appaled by the syntax and hope they will change it, otherwise I also wont use it. Is it so hard to making an extension with not many deviations from the syntax? That make me sad.
@@vimdiesel Yes this is 100% personal taste in syntax and honstely it is quite the stupid reason of me not using Rust because of the syntax. I just personally find it quite ugly and it feels like they tried to do everything different that you can do differently, other than curly braces, lol. I know other people like the syntax, and not using such a powerful language because of that is problably quite stupid in the long run, but right now I just feel its very ugly. And the same thing seems to be happening to "safe C++".
IMOH Rust has the best syntax for it features. Other languages do not have many rust features, so the syntax was not needed. Now than C++ wants those rust features, what syntax did they come up with?
@@danielt8880 I can understand that, many do like it. I personally dont. But in the end, its a personal preference ans also a thing of what youre used to. After programming in Rust for a little while, youd probably get used to it and its not that horrendous anymore. I'm personally just someone who likes the C syntax the most (although it could also be better).
I'm C++ dev. That "safe" syntax looks yuck AF! I'm pretty sure it won't go to std like this. I'd use Circle instead. It can be tweaked to look like Rust. Actually using idiomatic C++ with RAII and value semantics should make it tones safer. Problem is that there are dev's who write it like C and do not understand how to do things right. Rust from other hand has restrictions which don't allow to do things the "wrong" way. That's its strength. From the other hand, it is Rust's weaknes when you just need to try things and not care about "righteousness".
Kind of disagree with the last part, you can do "easy mode" Rust, you move fast and don't spend time debugging. However, learning Rust to do the easy thing is the hard part.
@@NotherPlebyeah, and as someone that is learning Rust in the background, it would be reeeally cool to have a way to not care at all and just make a mvp
@@NotherPleb When you need something fast and not really care that much about errors or design shifts all the time and you not sure how it will change or what right way is... Then Rust is not that good option if you're are not ultra Rust master and can refactor fast and have right intuition. And I as a C++ dev see, that it is mostly the question of language mastering. I'm doing some errors as any human being. But not that much. And design of code allows to do things pretty fast and pretty right. But it took 20 years to master.
@@GuilhermeHCardozo Use Box, slap "?" on results, clone when you fight the borrow checker, stick to data oriented designs and don't be afraid to slap an Arc. This is what I do for quick mvp, but you can only see these easy solutions if you already know Rust
This idea of separating safe and unsafe code might be the best thing that ever happened to C++. I'm so tired of learning these ugly rules about using completely standard tools in a way that doesn't catch UB or an unexpected exception. The most frustrating thing in c++ to me is seeing people spend time learning some fundamentally broken tools, only to achieve much less by putting in even more effort
I also recommend using RAII, smart pointers, iterating with ranges, using variant instead of union, etc. All of these choices eliminate common sources of UB; mistakes are caught by the compiler.
@@geek2145 This is where the whole essence of the problem lies. I'm sure that for every C++ problem there is a separate tool that solves it. But these tools need to be: 1) downloaded and attached to the project 2) kept updated 3) somehow dragged into CI 4) on 90% duplicate the work that the compiler has already done *repeat for each project So no, the fact that there is a tool that solves the problem does not make it much easier. The problem is in the language. The language needs to be fixed
Terrible idea. If you want safety, use Rust. The whole point of C++ is that it's not safe and it allows you to get in their and manually manipulate memory. If this gets adopted the language's whole purpose for existing disappears.
I love Rust and actively promote it, but any professional software developer knows it's not as simple as "rewrite it in Rust", or " just begin new projects in Rust". Companies often have millions upon millions of dollars invested into their engineering team and software stack, and switching that over to a new language is time consuming and expensive, and many small companies don't have the resources to do so. This is why a safe C++ is so compelling, because it only takes minimal training for a C++ engineering team to get up to speed and you don't have to change your ecosystem and software stack. We should be devoted to safe code, not a particular programming language.
Rusts' borrow checking is a complex heuristic* though. It will be hard to come up with a sensible standard that's compatible with the myriad features C++ already has and that can be implemented for all the different compilers that exist. I think a better approach would be linear types + some simple reference borrowing. It would essentially codify RAII in the type system and ensure that resources always have exactly one owner. * It doesn't have false positives, but without a deep understanding of the compiler you can't fully predict what it will allow.
I mean, sure the borrow checker seems nice, but any green-field cpp projects are quite easy to implement "safely". Ofc you CAN do.. fun stuff, but it's considered bad practice and basically prohibited by many coding rules. The real problem is with systems that use old compilers - usually embedded systems, with gcc 6 that doesnt even support cpp 11...
I like how the video on Theprimetime channel reacting this video of yours has more views and impressions than the original That guy didn't even include a link to your video because God forbid some of his viewers would come here and consume the content from its source, classic RUclips debauchery and it's so infuriating how some people can just steal away other's ingenuity and their ideas to make some low effort reaction videos
Sean has been working hard on this for years, and it's a viable option that's here now. No endless committee discussions while C++ goes the way of the dinosaurs. I'm all for it!!!
I like the work Sean has been doing to address the important aspects of C++ however the standards committee has other plans. The world will do better to debunk the C++ standard's committees dialog with government regulation bodies and show it up for what it is. This way C++ is outlawed sooner to make way for alternatives which may include 'circle' if the regulatory policy is written so. At this time the C++ committe only has hot air to show in this area, no code, no specification no compiler. Rust's problem is there is no committe, no alternative implementation, no standards specifications. Rust will do well to get its act together in this area if it wants to actually challenge and get regulatory status. Rust would do well to implement a small unix like OS entirely in rust to demonstrate to the world how it should be done. The learnings and feature advancement for rust makes this effort worth doing even if the kernel is not adopted my many.
At this point, I'm not sure what people mean when they say "safe." Safety in any language, including rust, is not a guarantee. It's always a choice. Cpp gives you the choice to write memory safe code by leveraging the expressive type system. It's already opt-in. You can make the choice.
What you mean by "safety" is not what Rust devs mean. It means "the program will fail to compile if it could possibly invoke undefined behavior" - memory safety is all about this compile-time check to ensure the type system won't fall apart. Memory safe languages like Rust and C# have this property, while C++ does not. In C++, it is trivial to accidentally cause a use-after-free or buffer overflow even when using the STL, and this can be seen in the number of memory safety vulnerabilities prevalent in all C++ codebases.
@@Kupiakos42 The unfortunate thing is, Rust will fail to compile if you abuse memory, but this fact is so oversold that a great many people think it will fail to compile if you write code that results in undefined behaviour at all.. which is simply not that case. Sure, it is more difficult in rust to do a buffer overflow, but that doesnt mean you can't write a bug at all. People need to understand this.
This is called putting the cart before the horse. Hardware is inherently unsafe, the CPU is a machine, and it is capable of unsafe operation. A subset of the machine's capabilities will always be an inferior representation of the maximum. Even assembler is already a subset, because most of us acknowledge that the micro sub-operations such as fetch, cache, and the use of ALUs is well tuned for the machine specs as they are given to us. Making a declaration such as, "You are not allowed to address memory yourself," as a general rule, is simply asinine. You may believe in the future, but some of us are actually responsible for hardware, and someone needs to write your compiler.
Very interesting take. I agree with you to some extent, however, I still think that putting safety constraints to a language is beneficial. If C++ is a language for this kind of constraints.. that's another topic :D
with every passing day, there are more and more incentives for me to stay in pure C89 and reject all of humanity's lame attemps at "advancements" in programming languages...
it would be cool if they just would stop adding stuff to c++, but start deleting shit. I mainly write C++ and in my opinion the main problem is that its tooo fucking bloated. Noone uses every C++ function.
I think we'll sooner have LLM's capable of transforming large C++ codebases into Rust than this proposal getting accepted and implemented by compilers on all platforms.
Critical systems and high performance systems had no safe alternative for decades and most of them need safety. The "skill issue" argument is so weak, with decades of training and best practices and still here we are, it's a "tool issue"
@@NotherPleb there's no reason to mangle c++ with safety. Just use a different language. It's ok for c++ to be unsafe. It's ok for another language to be preferred when specific forms of safety need to be formally guaranteed.
@@NotherPleb that sounds like a management problem, because formal verification of software has existed for many years at this point. If you want true safety, use a language like Idris that acts as a proof checker. Worried about accidentally forgetting an edge case or making an infinite loop? The Curry-Howard correspondence is here to help.
I do not intend my software to run on the core systems of a nuclear submarine, but on a domestic computer, seriously, what is it with all the paranoia about memory safety? Git gud!
Writing "unsafe" code in C++ is literally a skill issue nowadays, literally. Just use standard containers + smart pointers and 99% of memory issues are fixed. There, I said it. Rust is for those who combine politics with programming. For some reason...
You are empirically foolish: see the recent post "Eliminating Memory Safety Vulnerabilities at the Source" by the Android team. Stopping development of new C++ drastically reduces memory vulns. Anyone who claims to write perfect code all the time cannot be trusted.
@Kupiakos42 Interesting post you provided. Nevertheless, I wholeheartedly stand by what I said. C++ already has everything needed to be perfectly memory safe. Moreover, don't you think that the cases when you need to write unsafe cpp code, say use raw pointers, pretty much coincide with when you would use unsafe in rust? Low-level and 100% safe just don't go hand in hand
A superset of C++, this is like infinity times infinity. And there is probably already something to help with memory safety, smart pointers and containers to name a few.
Supersets all the way down!
@@cheesed_up yes! infinity-fold Cartesian products!
the syntax really looks like regex
LMAO that's actually a great description of what first comes to mind when seeing it
agreed
I disagree. I can actually read and modify regex.
I think C++ needs to adopt some kind of safety mechanism, and Rust's borrow checker is really the only option for them, so it makes sense to me. I do agree that the syntax is pretty awful, and unlike Rust (where syntax can change with editions while maintaining forwards/backwards compatibility), C++ has no way of changing syntax once codified into the standard.
Very insightful, thanks for the comment!
The proposal from this video comes from the circle project, which adds that idea of "feature on/off", so that you can enable and disable syntactic extensions with file granularity. The safe extension is one of that features, but the circle compiler have A TON OF syntactic extensions to C++. The leader of that project has tried to bring that idea to the standard committee through this proposal but I think the committee guys are far from convinced, and so I think this proposal is kinda dead already.
It won't stay that way anyway, that was an experimental syntax found in the Circle Compiler that Sean Baxter made before submitting this proposal, he didn't like p2996r5 (the C++26 reflection proposal) as it is but submitting for C++ he'll have no choice, the ^ will become the reflection operator, the ~as_pointer and ~as_length will not be viable and he'll have to rely on extending the reflection syntax for C++26 instead for that. So yeah the syntax isn't not only not set in stone, it is literally impossible for it to be like that. Personally I'd prefer if we had small keywords over the annoying ugly symbols anyway.
Cpp already has optional safety mechanisms, like smart pointers. People can choose to use them.
@@geek2145 There's not any reason to not have additional opt-in safety.
Syntax so ugly even most die hard C++ enjoyes bout to learn Rust
Have you ever seen rust code in huge projects? This is the most cursed s..t I ever seen. Stop being a sheep and think for yourself once
@@kerojey4442
Was it procedural style or functional style?
@@arkeynserhayn8370 Functional
@@kerojey4442
You know what?
By the time i made that comment and now that i read your reply, my opinion changed. Initially i only glanced a single rust program that was functional style, and that was pretty lean i thought maybe the problem with rust is the procedural style of writing, and functional style rust is okay; that is why i made the upper comment. Today, i glanced some other rust code, almost all of them functional style. Lets not talk about that . . .
@@arkeynserhayn8370 lol
I first thought this was some sort of new C++26 reflections syntax, this is a whole new meta programming language on its own.
i write c++ to be unsafe bro wtf i don't even use condoms why i should use memory safe languages
Bro garbage collects abortions 💀
@@RenderingUser
How do you know they cause pregnancy? Maybe they go the other way around 😂
@@arkeynserhayn8370 it's about as certain as writing memory leaks occasionally
@@RenderingUser ...or he does not go in v... 🤣
Pregnancy safe condoms include:intercourse time safety, constant memory offset from sperm to egg, prohibit copying memory-your DNA to unsafe location. And lastly they guarantee that cpu-woman who "ran" your "code" won't file post execution lawsuit.
Time to use pure C
Good luck if it survive after zig 1.0😉
@@rezabani9904 it's impossibile that C won't survive for many reasons (linux, vulkan, etc). But i agree that zig is far better for 2024, i don't want to use it right now only because it is not stable yet
ur take’s a loser’s take rezabani
@@rezabani9904 🤣
C ftw
With modern C++ practices one hardly encounter memory safety issues. When you use it in a C like way you run into above issues.
Many features that are now a widely used part of syntax (lamda, range based fors) have began life in other languages.
Long as the unsafe subset is default and/or the safety features are opt-in I don't see much of a problem.
as A C++ developer it would be a nice optional feature for developing very critical part of softwares like Drivers.
@@_AJ_12 this safe unsafe add so much noise that it's just better use conventional idiomatic (if possible) C++
@@danielmilyutin9914 this could easily mitigated by add something like "Prefered default" for borrow checking to the compiler options.
for those who like conventional idiomatic C++ can use legacy and dont even care about borrow checker.(safe and unsafe has no effect in this legacy mode)
@@danielmilyutin9914 the two security options can be used together, they are not a replacement for each other but offer complementary features. One of the features in the new proposal is the compiler makes compile time garuntees about the code inside the marked sections.
So now its possible to mandate that certain parts of a project (on a compile unit by compile unit basis) must be written with all the security options enabled. For example areas that interact with the outside world to sanity check data handling.
The point is expecting all developers to write idiomatic code just is not enough. They need a compiler flags that enforces the rules to do the secure thing.
C++ cannot be used as drivers. full stop. The EH sucks
@@coshvjicujmlqef6047 C++ compilers support compiling code with exceptions. I still wouldn't use C++ for drivers, though.
Looking into the proposal, seems like it is authored by "The C++ Alliance". How legit is the alliance though? The official organization behind C++ is "Standard C++ Foundation". The Wikipedia page for C++ doesn't mention the alliance.
At least it is opt in. When I need safety I just use Rust
Right now it seems that to convert an existing class from C++ to Safe C++ only requires rewriting about 95% of all the lines. And the lines that do not require rewriting are mostly "{" and "}" if you use Allman-8 formatting. I wish the syntax gets much nicer or it will be easier to use Rust and write a bridge between C++ and Rust in C.
Is it... really that hard to use smart pointers? Stick to unique pointers and bounds-checked containers for nearly everything and you'll be fine. Macro them too so they're shorter. This is the way I write all my C++ code nowadays anyway, and I've never had issues.
I'm newbie at programming. If carbon have memory safety. What's the point using rust?
Carbon is not yet a finished language. When it's done (if it's done) then we'll see how it does in comparison to Rust and C++ :D
real sigmas leak memory
wow that syntax looks ridiculous
Now just add everything from rust to guarantee C++ will be 80%+ safe
When people think smart pointers == safety, or thar rhis matter is just people wanting to use rust, you see how important the discussion is. I like C++, but it is true that without breaking changes tbe language will never catch up with real modern techniques and what toolig can do. New librart features cannot solve it, the language must enable things like safety, good straightforward meta programming and assist tooling functions
What about runtime overhead? Will that bind runtime overhead? Will it make code runtime slower?
To my knowledge, borrow checker doesn't add any runtime performance penalties - borrowing is essentially a set of compile-time "rules" for managing memory.
@@cheesed_up Yeah the borrow checker is all compile time. However, the safe alternative standard library does include more runtime code to enforce invariants (bounds checking, etc.). As with Rust though, I suspect these checks are entirely worth it from a performance perspective. Most Rust developers don't even bother with `*_unchecked` versions of functions since the performance is close enough.
@@cheesed_up I guess the prohibition of undefined behaviour and the restriction of certain features could cause overhead in terms of optimizations that can't be applied any more. The borrow checker itself won't cause runtime overhead because it's just a set of compile-time checks, but the way user must change the code to make it borrow-checker-friendly could probably cause some performance impact.
As I understand it the penalty is no different to Rust but its optional. A progressive language enhancement.
Yes there is a measurable runtime performance penalty (plenty of people have measured it in rust/cpp) but it isn't much.
The greater penalty is the loss of algorithmic shortcuts. That is something C++ is traditionally used to achieve. The safe sections prevent many of the turbo assembler style optimizations relying on undefined-behaviour or non-portable constructs that are designed to squeeze every last programmer knows better than compiler cpu cycle out of performance.
But its all optional, you get to choose, your employer gets to choose the regulatory body you need to comply with gets to choose. The best of all worlds for everyone and eventual end of discussion how do we make code safe from human error with the least expense.
Now a compile flag, don't want to code in that environment that's ok there are plenty of other roles and languages to do something else in the field.
The real issue is build time, C++ is extensively used in areas where iteration is in demand.
The latest C++ standard is (20)23 not (19)98.
How is it C++23 if we're in 2001? C++ this far ahead?
So it's a proposal where C++ gets another language embedded into it. You of course have to opt in to use it and it's probably going to be a billion new keywords and syntax. Sounds familiar doesn't it. The problem with C++ is the fact that it's too overbloated. If you need the safety features, you really don't have an option but use Rust.
c++ dev here and I am not interested in those proposal.
Also not Rust
its optional, i think.
@@AA-qv7fb then just use smart pointers??
@@geek2145 smart pointers dont guarantee memory safety. I hate it too but you MUST evolve as anything that falls under regulation is starting to be written in rust due to memory safety. there there is a proposal that ensures memory safety and allows for incremental adoption it must be looked at. either way dont use it if you dont want to, it isnt a must according to the proposal.
@@AA-qv7fb It can't be a must, because if it was it would break backwards compatibility, which is a requirement for c++. Let me be clear: I think safety by default is a great thing. If people or companies want that, then they shouldn't use c++. End of story. If you use a modern subset of c++, then memory errors will be extremely uncommon. The sanitizers provided by compilers can detect anything that slips between the cracks. The issue is that most devs do not do any of this. Most devs turn off compiler warnings that they find annoying. The issue isn't a lack of memory safety features in c++, there are more than enough. The issue is that developers don't use them. Because they don't care.
@@AA-qv7fb The issue of memory errors is primarily a cultural one. The benefit of safety-by-default is that the language enforces a certain perspective. You are required to care. You can't add that to c++.
Yuck.
While they are it, can they please steal rust's cargo as well? pretty please?
This
still waiting for modules support
Why? GNU Make or CMake+some make(incl. Ninja) for normal people. Vcpkg if you hate BSD and Linux users.
Can rust steal Gentoo's portage, pretty please?
Cargo is such ass. No.
C++ has had safe pointers for a very long time. Rust is a cult.
The problem isn't that you can't write safe code, the problem (as I understand it) is that the compiler cannot verify that the code you wrote won't produce undefined behaviour. What I find incredible is the idea that compilers are even able to verify that code is safe at all
@SamJamesCrawford that is not the job of the compiler... Nor it should be
I am still a C++ noob, but I have made at least one fairly big c++ project on my own. It was fairly easy, and I encountered very few issues. I am very curious about what all the "unsafe" talk even means? I only know modern c++, and have never used a raw pointer
@@LWmusik No raw pointers? come on you gotta use *some*
Reference counting doesn't make pointers safe. I think cuktish behavior is when people proclaim something based on their beliefs about something without actually understanding it
5:19
Rust: Look what they need to mimic a fraction of our power
Did you mean: "look how they massacred my boy"?
the syntax bro
To be fair, I used the worst example there is :D ... but yeah...
The biggest reason I dont use Rust is because of the ugly syntax. Call me stupid, but its just not fun.
I was thrilled to hear that C++ is considering implementing safe code with a borrow checker.
I was appaled by the syntax and hope they will change it, otherwise I also wont use it. Is it so hard to making an extension with not many deviations from the syntax? That make me sad.
Can you elaborate?
I don't think rust is that much uglier than c++
And the functional style looks much cleaner in rust
@@vimdiesel Yes this is 100% personal taste in syntax and honstely it is quite the stupid reason of me not using Rust because of the syntax. I just personally find it quite ugly and it feels like they tried to do everything different that you can do differently, other than curly braces, lol. I know other people like the syntax, and not using such a powerful language because of that is problably quite stupid in the long run, but right now I just feel its very ugly. And the same thing seems to be happening to "safe C++".
IMOH Rust has the best syntax for it features. Other languages do not have many rust features, so the syntax was not needed. Now than C++ wants those rust features, what syntax did they come up with?
@@danielt8880 I can understand that, many do like it. I personally dont. But in the end, its a personal preference ans also a thing of what youre used to. After programming in Rust for a little while, youd probably get used to it and its not that horrendous anymore. I'm personally just someone who likes the C syntax the most (although it could also be better).
From Primeagen
I'm C++ dev. That "safe" syntax looks yuck AF!
I'm pretty sure it won't go to std like this.
I'd use Circle instead. It can be tweaked to look like Rust.
Actually using idiomatic C++ with RAII and value semantics should make it tones safer.
Problem is that there are dev's who write it like C and do not understand how to do things right.
Rust from other hand has restrictions which don't allow to do things the "wrong" way. That's its strength.
From the other hand, it is Rust's weaknes when you just need to try things and not care about "righteousness".
@@danielmilyutin9914 This is Circle
Kind of disagree with the last part, you can do "easy mode" Rust, you move fast and don't spend time debugging. However, learning Rust to do the easy thing is the hard part.
@@NotherPlebyeah, and as someone that is learning Rust in the background, it would be reeeally cool to have a way to not care at all and just make a mvp
@@NotherPleb When you need something fast and not really care that much about errors or design shifts all the time and you not sure how it will change or what right way is... Then Rust is not that good option if you're are not ultra Rust master and can refactor fast and have right intuition.
And I as a C++ dev see, that it is mostly the question of language mastering. I'm doing some errors as any human being. But not that much. And design of code allows to do things pretty fast and pretty right. But it took 20 years to master.
@@GuilhermeHCardozo Use Box, slap "?" on results, clone when you fight the borrow checker, stick to data oriented designs and don't be afraid to slap an Arc. This is what I do for quick mvp, but you can only see these easy solutions if you already know Rust
This idea of separating safe and unsafe code might be the best thing that ever happened to C++.
I'm so tired of learning these ugly rules about using completely standard tools in a way that doesn't catch UB or an unexpected exception.
The most frustrating thing in c++ to me is seeing people spend time learning some fundamentally broken tools, only to achieve much less by putting in even more effort
If you're worried about UB, then run UBSan and ASan. That catches most mistakes.
I also recommend using RAII, smart pointers, iterating with ranges, using variant instead of union, etc. All of these choices eliminate common sources of UB; mistakes are caught by the compiler.
@@geek2145 This is where the whole essence of the problem lies. I'm sure that for every C++ problem there is a separate tool that solves it.
But these tools need to be:
1) downloaded and attached to the project
2) kept updated
3) somehow dragged into CI
4) on 90% duplicate the work that the compiler has already done
*repeat for each project
So no, the fact that there is a tool that solves the problem does not make it much easier. The problem is in the language. The language needs to be fixed
@@geek2145 Of course i know all of this recommendations. I only wish that they become default in some way
@@ИгорьСавенков-и3х these sanitizers are built into gcc and clang. It's only an extra flag away.
I don't like it and if it gets standardized I won't be using it.
++
Terrible idea. If you want safety, use Rust. The whole point of C++ is that it's not safe and it allows you to get in their and manually manipulate memory. If this gets adopted the language's whole purpose for existing disappears.
Yeah, sometimes I want to blow my foot off
C++, just be yourself
bee*
I love Rust and actively promote it, but any professional software developer knows it's not as simple as "rewrite it in Rust", or " just begin new projects in Rust". Companies often have millions upon millions of dollars invested into their engineering team and software stack, and switching that over to a new language is time consuming and expensive, and many small companies don't have the resources to do so. This is why a safe C++ is so compelling, because it only takes minimal training for a C++ engineering team to get up to speed and you don't have to change your ecosystem and software stack. We should be devoted to safe code, not a particular programming language.
Funny video!
Wow, they somehow made syntax WORSE than Rust!
It's about damn time! congrats!!
Rusts' borrow checking is a complex heuristic* though. It will be hard to come up with a sensible standard that's compatible with the myriad features C++ already has and that can be implemented for all the different compilers that exist.
I think a better approach would be linear types + some simple reference borrowing. It would essentially codify RAII in the type system and ensure that resources always have exactly one owner.
* It doesn't have false positives, but without a deep understanding of the compiler you can't fully predict what it will allow.
If you'd like to learn more about this, I highly recommend reading the article "Introducing Austral".
(just beware some harsh C++ and Rust criticism)
Sounds interesting, I'll check it out!
I mean, sure the borrow checker seems nice, but any green-field cpp projects are quite easy to implement "safely". Ofc you CAN do.. fun stuff, but it's considered bad practice and basically prohibited by many coding rules.
The real problem is with systems that use old compilers - usually embedded systems, with gcc 6 that doesnt even support cpp 11...
I like how the video on Theprimetime channel reacting this video of yours has more views and impressions than the original
That guy didn't even include a link to your video because God forbid some of his viewers would come here and consume the content from its source, classic RUclips debauchery and it's so infuriating how some people can just steal away other's ingenuity and their ideas to make some low effort reaction videos
He did include a link. That's how I got here.
I know what you mean, however he did include a link and gave a shoutout! But yeah, youtube is weird :)
Just use C# or Java at that point?
I know what you are trying to say... but not a big fan of any of these two though :')-.
@@cheesed_up **Sadge C# noise*
cppfront > carbon
Sean has been working hard on this for years, and it's a viable option that's here now. No endless committee discussions while C++ goes the way of the dinosaurs. I'm all for it!!!
Me too!!
one smart, determined guy is always better than a bureaucratic committee
@@TheSulross 💯
It's about time
I like the work Sean has been doing to address the important aspects of C++ however the standards committee has other plans.
The world will do better to debunk the C++ standard's committees dialog with government regulation bodies and show it up for what it is.
This way C++ is outlawed sooner to make way for alternatives which may include 'circle' if the regulatory policy is written so.
At this time the C++ committe only has hot air to show in this area, no code, no specification no compiler.
Rust's problem is there is no committe, no alternative implementation, no standards specifications. Rust will do well to get its act together in this area if it wants to actually challenge and get regulatory status.
Rust would do well to implement a small unix like OS entirely in rust to demonstrate to the world how it should be done. The learnings and feature advancement for rust makes this effort worth doing even if the kernel is not adopted my many.
At this point, I'm not sure what people mean when they say "safe." Safety in any language, including rust, is not a guarantee. It's always a choice. Cpp gives you the choice to write memory safe code by leveraging the expressive type system. It's already opt-in. You can make the choice.
What you mean by "safety" is not what Rust devs mean. It means "the program will fail to compile if it could possibly invoke undefined behavior" - memory safety is all about this compile-time check to ensure the type system won't fall apart.
Memory safe languages like Rust and C# have this property, while C++ does not. In C++, it is trivial to accidentally cause a use-after-free or buffer overflow even when using the STL, and this can be seen in the number of memory safety vulnerabilities prevalent in all C++ codebases.
@@Kupiakos42 Cpp has smart pointers, that's exactly what I mean.
@@Kupiakos42 you can choose to use memory safe features of Cpp. Conversely, you can choose to write unsafe rust.
@@Kupiakos42 The unfortunate thing is, Rust will fail to compile if you abuse memory, but this fact is so oversold that a great many people think it will fail to compile if you write code that results in undefined behaviour at all.. which is simply not that case. Sure, it is more difficult in rust to do a buffer overflow, but that doesnt mean you can't write a bug at all. People need to understand this.
@@geek2145 Smart pointers make it easier to do memory management. It is the barest form of safety, and does not meet modern standards.
This is called putting the cart before the horse. Hardware is inherently unsafe, the CPU is a machine, and it is capable of unsafe operation. A subset of the machine's capabilities will always be an inferior representation of the maximum. Even assembler is already a subset, because most of us acknowledge that the micro sub-operations such as fetch, cache, and the use of ALUs is well tuned for the machine specs as they are given to us. Making a declaration such as, "You are not allowed to address memory yourself," as a general rule, is simply asinine. You may believe in the future, but some of us are actually responsible for hardware, and someone needs to write your compiler.
Very interesting take. I agree with you to some extent, however, I still think that putting safety constraints to a language is beneficial.
If C++ is a language for this kind of constraints.. that's another topic :D
the proposed syntax looks so bad, id rather just use rust lmao
with every passing day, there are more and more incentives for me to stay in pure C89 and reject all of humanity's lame attemps at "advancements" in programming languages...
bruh
@@fullaccess2645
There is nothing, literally NOTHING that is computationally possible in other programming languages that you cannot do in C89.
I know what you mean....
With every passing day, there are more and more incentives for me to shout at kids to get off my lawn. Getting old is not fun.
it would be cool if they just would stop adding stuff to c++, but start deleting shit. I mainly write C++ and in my opinion the main problem is that its tooo fucking bloated. Noone uses every C++ function.
I think we'll sooner have LLM's capable of transforming large C++ codebases into Rust than this proposal getting accepted and implemented by compilers on all platforms.
"Memory safety is very important, always free your memory" 🤓
Womp womp, skill issue
Safe is boring
literally just write better code (this is not sarcasm)
if you are in dire need of safety then don’t use c++
Critical systems and high performance systems had no safe alternative for decades and most of them need safety. The "skill issue" argument is so weak, with decades of training and best practices and still here we are, it's a "tool issue"
@@NotherPleb there's no reason to mangle c++ with safety. Just use a different language. It's ok for c++ to be unsafe. It's ok for another language to be preferred when specific forms of safety need to be formally guaranteed.
@@geek2145 I agree! But for a long time there was only C++ even when safety is a requirement but the "just write better code" never scaled.
@@NotherPleb that sounds like a management problem, because formal verification of software has existed for many years at this point. If you want true safety, use a language like Idris that acts as a proof checker. Worried about accidentally forgetting an edge case or making an infinite loop? The Curry-Howard correspondence is here to help.
C++ is slowly but surely turning into a clone of Rust with a worse standard library
And a better non-standard library*
I do not intend my software to run on the core systems of a nuclear submarine, but on a domestic computer, seriously, what is it with all the paranoia about memory safety? Git gud!
Yea. It's not a big deal if domestic computers get hacked because of undefined behaviour
@@levaniandgiorgi2358 who lets their program run with undefined behaviors? Not me.
Writing "unsafe" code in C++ is literally a skill issue nowadays, literally. Just use standard containers + smart pointers and 99% of memory issues are fixed. There, I said it. Rust is for those who combine politics with programming. For some reason...
You are empirically foolish: see the recent post "Eliminating Memory Safety Vulnerabilities at the Source" by the Android team. Stopping development of new C++ drastically reduces memory vulns.
Anyone who claims to write perfect code all the time cannot be trusted.
@Kupiakos42 Interesting post you provided. Nevertheless, I wholeheartedly stand by what I said. C++ already has everything needed to be perfectly memory safe. Moreover, don't you think that the cases when you need to write unsafe cpp code, say use raw pointers, pretty much coincide with when you would use unsafe in rust? Low-level and 100% safe just don't go hand in hand
Bad proposal at that point make a new language.
Too much technical debt and nerfing its own capabilities by borrow checking with a price tag of ugly syntax. Time to consider zig/odin/c3.