No more includes/header files seems to imply no more preprocessor, which is a shame because while it may have been hackish, it was one of c's greatest strengths.
> more logical keywords (public/local replaces static)
My friends, have you heard of the wonderous c preprocessor?
#define local static
For a slightly nicer alternative to c, what about zig?
I agree. What caught my eye was how they kept C's "clockwise/spiral" rule for declarations. If their goal was to actually improve the language over C then it makes no sense to keep one of C's main shortcomings. Heck, even C++ improved on this problem by introducing support for trailing return type declarations in C++11.
In addition, it appears C2 still lacks support for anonymous functions, which is simply absurd in today's age.
The documentation goes on at some length about how the C2 compiler parses and analyzes all source files at once, before generating code. Supposedly this improves compilation speed because:
The code generation (and optimization) steps require a lot of time. So if you have 100 C source files and the 99th file has a syntax error, the compiler has to go through a lot of work before showing the diagnostic. In C2 it only takes very little time. So during development, developers never have to wait for diagnostic messages.
Except that during development of C programs, in practice, most changes will only require recompiling one or two files. The rest of the files have already been compiled and don’t have to be examined at all until the link step, which is relatively fast.
Admittedly, C is simple enough, and the header file and process-per-source-file models inefficient enough, that the C2 compiler might be able to parse and typecheck 100 files in an amount of time similar to what make and clang take to build two. I haven’t tested it, but let’s assume so. Then if I have an error, I indeed wouldn’t have to “wait for diagnostic messages” (for too long, anyway). And it would be nice that the same speed could be achieved regardless of what I change, whereas in C touching a common header file may well require rebuilding everything. Then again, this fundamentally doesn’t scale well.
But what if I don’t have an error? With an incremental C build, I don’t have to wait to run and test my code, either. If the C2 compiler doesn’t support incremental compilation, it’ll have to redo code generation for everything, using the same backend (LLVM) as my C compiler. Thus, the ‘feature’ of compiling everything at once becomes an antifeature.
It is possible to implement incremental compilation in a compiler more ‘natively’ than C’s file-based approach, and this can turn module-at-once compilation from a mixed bag for performance to a pure win. If the C2 compiler has done so, I shouldn’t be complaining! But since it’s not mentioned in the documentation pages I looked at, I’m guessing it hasn’t.
I don't count Rust, because one of the good things about C is that it's quite easy to write a compiler for. A better C shouldn't require a too clever compiler.
Another attempt I stumbled across recently is Zig: http://ziglang.org
Why is that relevant?
deb/rpm files or at least a PKGBUILD would help make it a lot more accessible.
I also don't think a mutable variable is bad or hard to use. Is this bad/hard to use?
for (int i = 0; i < 10; i++)
int line_number = 0;
while (read_line_from(stdin, &line))
// TODO handle line
line_number += 1;
What inherently makes this
for (mut int i = 0; i < 10; i++)
If you're actually against mutability where it doesn't need to be you can create tooling that can warn you of where you can add const. I think that's much better.
Variables, both in ordinary mathematics and in the semantics of programming languages, are given meaning by substitution, not mutation. This is true even in the semantics of imperative languages.
(arguably, the only thing easy to do in assembler that you cannot comfortably write in C)
but assuming that I think they should just have pulled in the type syntax from Go