Introducing keywords in front of declarations is actually a required syntactical change to make the syntax context-free, i.e. to avoid having to carry around a symbol table during syntax parsing, as C requires. (Well, another method would be something like "declaredname :: type { impl }" but it requires more lookahead and it's a much more different syntax).
And all modern languages have added something like this. Personally I'm used to the C way and I like it for its terseness, but the modern approach allows for simplified parsers and better tooling.
In fact C started out like that just as well: There were only a constant number of keywords, like int, void, struct... that could introduce a declaration. But, with the advent of typedef (and C++ which automatically removes the need for the struct tag for all struct definitions) that changed, and in effect a symbol table is now required for parsing.
I agree there is a need for easy transition, but I think that ease mostly comes from being able to be compiled and linked in existing tool chains like this project does.
I wrote a C compiler as well, got as far as compiling a hello world and all the includes it needs on a standard Linux or MacOS system. My plan was to have a sort of strict option that would be enabled if you wanted to use the new features like modules and namespaces, and the strict option would error on problematic C code.
Anyway I stopped the project when Rust released their first version without garbage collection. It seems to me they solved all my concerns and they didn't even need to integrate C itself.
Illustrates why projects don't do this:
> If you're breaking backwards compatibility anyway, why not go all the way?
Rust usage, even with millions of dollars of marketing and eleven years of hype, is still almost a rounding error in terms of usage.
Within the tiny set of scenarios where Rust is applicable as of now, isn't it completely dominating?
It's dominating in hype and excitement for toy and pet projects. This is just the first few steps. Too few people have dabbled enough yet.
The next step is enough stability/maturity that more open source and maybe fang infrastructure can use it. And when the reasoning behind this becomes widely digested, most "green field" projects will choose Rust.
But that may be ten years away?
But that's not the right comparison. The use of the C language itself is a rounding error compared to all the languages that replaced it. Java, C#, C++, Python, Javascript, Go, they all replaced most use cases of C in modern programming. Rust is just attacking the last vestiges of C's usefulness.
One tiny hobby language I use was changed to accept semicolons as an additional end-of-line, just to allow more easy copy-pasting of C code. It's surprising how portable C is in that sense too. If you're going C-style, probably best to stick C-style. (But I used fn in my own C-alike... who am I to judge?)
`num_value = enum_value`... that might actually happen. I haven't decided.
"`char str` into cstring str"... no? The whole story with strings haven't been 100% decided yet, but likely this will be: `char str` raw character string `char[]` a string slice, preferred over null terminating char*, and finally `String` which is a userland, dynamic string.
Something you can do with C3 is that you can convert as much or as little you want from C to C3. C3 is ABI compatible with C, so you can just compile using the C3 compiler for some files and then with GCC or Clang the C files. In fact I did this with vkQuake, converting a little bit of code into C3 and removing that from the .c files, then compiling the C3 code with c3c and the C code with Clang, then linking it together and it runs as if all had been written in C.
https://twitter.com/nuoji/status/1417212252843880451
Edit: And regarding `func` it's for easy parsing and greping for IDEs and editors.
A better C should just be like what Apple is doing for iBoot, or Microsoft with Checked C, by disabling what makes C unsafe while being mostly compatible.
Changing stuff like
- ptr = array into ptr = &array[0]
- num_value = enum_value into num_value = base_value(enum_value)
- char *str into cstring str
- char str[10] into a proper array without pointer decay (alternatively like cstring, a new array like type declaration)
If it is C like, while requiring major code rewrites, then it is just another attempt, regardless of how much valuable work has been put into it.
C++ got its adoption by having been born in the same place as C and UNIX, as C pre-processor with zero friction in C toolchain, hence why it was quickly adopted by C compiler vendors.
Any C replacement needs the same ease of transition, specially for domains that will never move beyond C, because reasons.