The problem here is you’re not writing C, you’re writing a language that kind of resembles C but is nonportable. So you might as well just use a different, memory safe language at that point.

Checked C’s design is distinguished by its focus on backward-compatibility, incremental conversion, developer control, and enabling highly performant code

The problem is that there is a huge body of decades-old C code out there that we all depend on.

A typical Docker container with a web app contains maybe 10K lines of your own code in Python/Ruby/JS, 100K lines of framework code, and 1M or 10M lines of C code (i.e. the interpreter itself, the web server, SSL, the base image, etc.)

So I welcome new languages focused on incremental conversion.

That's what I'm doing with Unix shell: http://www.oilshell.org/blog/2018/01/28.html

I applaud projects like Corrode, a C to unsafe-Rust translator, although undoubtedly they would have an easier time if Rust was designed in the first place for conversion.

https://github.com/jameysharp/corrode

So Checked C seems like a great idea to me.

I've noticed that most programmers seem to wildly overestimate the rate at which code gets rewritten. I think it's more accurate to say that code piles up over time. And unfortunately when the foundations are unstable, what you build on top is also unstable.