Comment by foldr
I don't think it makes sense to compare non-invariant-respecting unsafe blocks to compiler bugs. It would make sense to do so if unsafe blocks were only present in a highly-verified Rust stdlib, but we both know that's not the case.
>Crucially unsafe Rust doesn't have weaker rules, it has the same rules, that's my whole thrust here. The change is that the burden of obeying those rules is on you, the programmer, and that's a heavy burden.
Now we're circling back to my argument about C. The C standards committee could declare that 'unsafe C' (i.e. all C) has these very same rules (which C programmers have the heavy burden of obeying). Would this instantly convert C into a memory safe language? Of course not! It's an empty semantic gesture. Similarly, merely saying "Rust programmers are obliged to respect the following invariants inside unsafe blocks!" does nothing to actually decrease the risks associated with unsafe blocks (leaving aside whatever exhortive success such admonitions might have).
What next, if we accept this logic? Is Perl a language with strict static typing, but "the burden of checking the types falls on you, the programmer"?.
> Would this instantly convert C into a memory safe language?
I actually strongly encourage finishing this thought. Imagine you're WG14 and you're intending to drop this "safe C" bombshell in C29 and think about the implications just for your document.
You "just" need to spell out all these rules for the language itself, Rust only has a handful but you've got pages of these, and then you need to go re-design all your APIs so that instead of basically YOLO† each of the standard library APIs has an explicable set of safety requirements, just as Rust has to do with its relatively small subset of unsafe APIs.
A subset of this work is already underway for WG14 and has been for a few years. You'll need to hurry them along to prepare for your epoch making announcement because they're not expecting to be anywhere close by 2029 but hey, shoot for the stars right?
At the end of this, you've announced a deeply incompatible C version and the benefit is that if your customers can hire people who don't make mistakes and they port all their C to this new version, it has similar properties to if they were to rewrite it in Rust. Don't expect applause, in fact, I'd recommend hiring bodyguards.
† I think people really underestimate how much C relies on this. Remember C provides qsort, an unstable type-erased comparison sort (hopefully an introsort, but in some implementations literally just Hoare's Quicksort which is significantly older than C itself) which has arbitrary Undefined Behaviour if you screwed up your comparison function and yet for all the popular implementations it's still slower than in Rust which doesn't have that UB problem at all.
So now you're documenting specifically for functions like this why "safe C" is both much harder to use and slower in your standards document like it's an achievement, and unlike Karoline Leavitt you're not even getting paid to do this. Maybe you should take up knitting instead?