New Safe C++ Proposal

[helios]

The difference between our two examples is one is elective while the other is necessary for survival.

You called out a slippery slope. The slope doesn't go away just because of the nature of the surgeries being performed. It seems the particular example is distracting you, so let's change it. You have a car that's not working properly and needs some fixes. It's not completely non-functional, it just shuts off on its own from time to time. Also occasionally it lets a burglar into your house. At what point do you stop fixing it to keep yourself from slipping down the slope?

C++ does not even fit that yet. Again, nothing can be done about integer or stack overflows.

You can write correct programs despite C++ not helping you at all there. It just falls on you to be constantly mindful of what you're doing. But it doesn't stop you from being safe, it just doesn't help you. There's literally no language that doesn't guarantee you can be safe. The only conceivable one would have to be a language that requires its compiler to non-deterministically insert errors into its generated code. That would be a language guarantees neither correctness nor incorrectness.

[zapshe]

It seems the particular example is distracting you, so let's change it. Also occasionally it lets a burglar into your house. At what point do you stop fixing it to keep yourself from slipping down the slope?

The issue is that these examples are not comparative to the actual situation. Let's say you fix up the car so good its just as good as a new car. Why stop there? The car is still dangerous, right? Program AI driving assist, add sensors everywhere, have a doctor in the car at all times too while you're at it just in case there's a medical emergency in the car.

It simply doesn't work whatever it is you're trying to prove. C++ is not broken just because its not perfect. A car that doesn't drive itself or prevent 100% of accidents is not a broken car, its just a car.

That is what your expectation of C++ is. Not just a language that gives you all the safety features but you can drive yourself off a cliff if you want, but a language that forbids you from ever doing anything that could ever potentially cause damage.

You can write correct programs despite C++ not helping you at all there

I shouldn't have to be pedantic about what I meant when I said a language that guarantees you "can" be safe.

If we go by your surface level interpretation of this, even a language that will take any line of code you write and turn it into some other random line of code with a high probability of UB would fit the description you interpreted, since you can be 100% safe by not writing any code in this language.

You simply cannot defend yourself against overflows in C++. You can use a custom variable type that won't overflow and replace all recursive solutions with iterative ones, but that goes against the point of me being guaranteed that I can be safe when coding things that SHOULD be safe.

Yes, you can be 100% completely safe, but that's not the point. The point is that I can be 100% completely safe doing regular coding as usual (unless it cannot be safe by nature, such as pointer arithmetic - which it can be safe technically but the performance hit would remove a valid reason for using it to begin with).

This means if C++ has the capacity for higher safety without changing how the programmer codes, then it hasn't fulfilled all the safety it should implement so you "can" be safe.

[helios]

The car is still dangerous, right? Program AI driving assist, add sensors everywhere, have a doctor in the car at all times too while you're at it just in case there's a medical emergency in the car.

Sure, why not?

Not just a language that gives you all the safety features but you can drive yourself off a cliff if you want, but a language that forbids you from ever doing anything that could ever potentially cause damage.

No. It doesn't need to forbid it. I just shouldn't be able to do it accidentally (i.e. while doing something totally innocuous). I've said time and time again, C++ makes it too easy to inadvertently stray from safety. It places too much burden on the programmer to remember which features are safe when.
Rust's and C#'s solution is this is good. Unsafe features are outright forbidden, except in unsafe blocks. If your program doesn't need unsafe features, you just don't use them, and you're secure that you don't have exploits at the source code level. Any language that gives the programmer raw memory access should do the same. There's no reason to let you mix that kind of control with normal code arbitrarily (in a language designed in a vacuum, of course).

You simply cannot defend yourself against overflows in C++. You can use a custom variable type that won't overflow and replace all recursive solutions with iterative ones, but that goes against the point of me being guaranteed that I can be safe when coding things that SHOULD be safe.

Yes, you can be 100% completely safe, but that's not the point. The point is that I can be 100% completely safe doing regular coding as usual (unless it cannot be safe by nature, such as pointer arithmetic - which it can be safe technically but the performance hit would remove a valid reason for using it to begin with).

This means if C++ has the capacity for higher safety without changing how the programmer codes, then it hasn't fulfilled all the safety it should implement so you "can" be safe.

So... After re-reading this like six times, what I'm getting from this is that you want C++ to contain as little UB as possible by changing its semantics but not its grammar, so that your valid programs remain valid (i.e. "you don't need to change how you code").
That's simultaneously a very modest and very ambitious requirement. Modest because there's not that much that can be fixed that way, and ambitious because while the grammar may stay the same, changing the semantics will still break people's programs, and more subtly, and there's no way people will agree on which way to break it.

[zapshe]

Sure, why not?

Because we can both agree up to a certain point. However, even if we both agreed it would be "better" for there to be doctors in cars, we would also agree this should never be mandated. Hence, you can't argue that we should keep making something safer and safer and screw everything else because even YOU would not want that. We are simply disagreeing at where the line should be drawn.

There's no reason to let you mix that kind of control with normal code arbitrarily

But as a C++ programmer, you already know this going in. You know you're working with a low-level language. You know they give little guardrails. You know it is up to you to deal with memory and everything. All the dangerous features give us intuition we're first starting out and fail with them. I simply don't like the idea of making it so safe, it would require such an overhaul of the language.

And all for what? We already have Rust. I don't hate Rust and I don't think people should not use it. I'm basically saying C++ has a lot of room to give defined behavior to things which are current UB and room for creating alternative safe coding routes. But to argue for overhauling the language for safety? That's just creating another Rust language, and you can't argue (successfully) otherwise.

After re-reading this like six times, what I'm getting from this is that you want C++ to contain as little UB as possible by changing its semantics but not its grammar

It's important for C++ to maintain backwards compatibility, period. This is better for the language and keeps programmers from having to learn anything new. C++ has never been about that.

If I wanna get lost in overhauls and code-changes, I'd program everything in C#. I appreciate C# getting better, but it's annoying. C++ has never been for such overhauls.

changing the semantics will still break people's programs, and more subtly, and there's no way people will agree on which way to break it.

It depends, I don't necessarily think people's programs would break. For example, if your integer overflows, you should probably assume it simply wrapped around - many compilers do that already.

Stack overflow? ANY solution will be fine, as there's no way for the programmer to have any safety against it already.

Going beyond an array's bounds? Crash I guess? Any program doing so is already broken, you can't break it further.

Does your program get away with de-referencing a pointer you already freed? Crash. Again, the program is already broken and cannot be broken further with this fix.

Uninitialized variables? Give them a default value... maybe. I actually kind of like having a random number in there. However, that's still UB still we don't know what to expect from an uninitialized variable, some compilers do give them a default value.


There's just SO MANY of these that can be fixed up and make the language a lot better without anyone possibly being upset.

But apparently the biggest issue is that my pointer arithmetic isn't in an unsafe context? It feels like we're talking about sex and it's getting shamed for doing it in public.

[helios]

https://news.ycombinator.com/item?id=42231489

I've been reading quite a bit about WG21, discussions surrounding Safe C++, etc. the last couple days. It turns out that the guy who wrote the Safe C++ proposal wrote his own C++ compiler from the ground up and added Rust-like static checking on top. The compiler is called Circle. Pretty impressive stuff, I'll have to check it out later.

Meanwhile, a few hours ago I noticed that Visual Studio stopped linking by project after updating, complaining that I was mixing static and dynamic runtimes (I'm not). And they had finally fixed the issue where the 2022 toolchain doesn't show the stack trace when you get a template error, too!
It doesn't have anything to do with this, but I wanted to complain about it.