[hgs3]

C is still evolving. Instead of creating a new C dialect, why not try improving C itself? You can prototype new features with Clang and submit a technical proposal to the C committee for review. Regarding "memory safety" specifically, many of the challenges folks face with RAM management are related to bounds checking so consider prototyping a slices concept [1].

[1] https://www.digitalmars.com/articles/C-biggest-mistake.html

[colonial]

The problem with this is that even seemingly basic, obviously desirable proposals can take years of labor and politicking to get through the committee. See JeanHeyd Meneide's valiant struggle to get an #embed preprocessor directive standardized [1] - it took five years, and I'm pretty sure the C++ equivalent (std::embed) is still in the oven.

When faced with that, it's only natural that people lean hard towards dialects and new languages. They move faster (Rust went from a standing start to 1.0 in ~five years) and offer far more freedom.

[1]: https://thephd.dev/finally-embed-in-c23

[hgs3]

C2Y, the next C revision, introduced "enable safe programming" into the C standard charter [1]. The C committee is eager for proposals like this.

Adding a new feature, like slices, as a Clang extension would be considerably faster than creating a new dialect or language, and it would be immediately usable by every C codebase building with Clang. Even if the feature is "slow" to be incorporated into the standard, it would still be accessible as a compiler extension in the interim.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3223.pdf