Earlier quoted context omitted.
> 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…
You’ve kindly finished the thought for me. You now have a “safe” version of C purely by updating the standard and associated documentation. (It’s not actually true that you need to redesign all the APIs in the stdlib. You just need to document the appropriate restrictions on how they may safely be used, just as you would have to do with a Rust function marked ‘unsafe’. It’s trivially possible to write an unsafe-marke…
That's exactly the problem. Notice how that C API qsort has basically the same affordance as the Rust sort_unstable (except it is type erased) but it has a lot more restrictions because C was a New Jersey language, what matters is that it's easy to implement. So you need to figure out (for some of the API I expect this may be a many years study) what the requirement are that you're going to document.
Or, which I'm confident will often be faster, reform the API and provide the thing programmers actually wanted anyway, the "Right Thing", which means more work for an implementer of your "Safe C" and also, which was my point, actually does get you a safer result after all.