I'm working on a "alternative to C" called C3, but unlike most (e.g. Zig, Odin, Jai, Rust etc) it tries to stay really close to C syntax as far as possible and I'd love to hear what people like and what they dislike, especially if they write a lot of C.<p>The site here has an overview of the language and code samples: http://www.c3-lang.org<p>You can try it out in the browser here: https://ide.judge0.com/?1EFo with the list of implemented features/not yet implemented features in the compiler found here: https://github.com/c3lang/c3c<p>Currently the spec has a bit too many features so I will try to remove the superfluous to make the language more easy to grasp in its entirety.<p>The syntax tries to stay true to C, with things added on top that C can't easily add due to backwards compatibility:<p>- Module system<p>- Generics<p>- Semantic Macros<p>- Error handling<p>- Defer<p>- Value methods<p>- Associated enum data<p>- Subtypes (Go's embedded structs)<p>- Optional contracts<p>- Built-in strings, maps, subarrays and vararrays<p>P.S. I know the change to use `func` with functions is controversial – it's great for a simpler grammar and to make function types stand out, but is quite a departure.<p>P.P.S. "Why not just use C?" Well, we're seeing C++ inspired languages (like Rust) taking mindshare both from C++ and C communities. I would like to see an alternative that keeps to the simplicity of C code instead of taking C++ syntactic complexity as a base line.
Here are the things I would need to migrate from C/C++/Rust to a new language:<p><pre><code> Automatic memory management, with optional manual control,
no garbage collection.
A universal or widely accepted build system (Cargo, CMake)
A public package registry and dependency resolver, designed
for deterministic builds, multiple versions of the same
package on one machine, etc, and support for private/proprietary
registries (Cargo, Conan)
A modern query-oriented/reactive/responsive (non-batch) compiler,
that supports static analysis, linting, language server features,
AST traversals/queries, etc.
Support for debugging with GDB/LLDB.
A (substantial) subset of the language with a stable ABI.
Fast debug builds, fast release binaries.
</code></pre>
Syntax/semantics of the language are significantly less important to me than all of the above.
<p><pre><code> /**
* @ensure const(foo), const(bar.x)
**/
</code></pre>
Does the compiler see inside comments? I think that Python does that for types because they want to preserve backward compatibility, but I never like it. Why not something like:<p><pre><code> #ensure const(foo), const(bar.x)
</code></pre>
or<p><pre><code> @ensure const(foo), const(bar.x)</code></pre>
I might like to have, in a better version of C:<p>- GNU extensions, such as zero-length arrays, ?: with nothing in between, and statements inside of expressions<p>- Less confusing syntax for types<p>- Full LLVM features<p>- Non-Unicode<p>- Both normal include files and token macros, as well as namespacing and hygienic macros supported too<p>- Standard macros for testing alignment, endianness, etc<p>- Macros that can call compile-time execution of codes which can deal with the AST<p>- Reduced runtime requirements<p>- Support for setjmp/longjmp with catch blocks; if you longjmp past such a block, it should execute the catch block to clean up as needed before that block jumps again back to the target of the longjmp operation<p>- The goto command.<p>The worst thing about C is I think the confusing syntax for types. Pointer arithmetic and goto are both good, though, so keep those.<p>I can do without automatic memory management.
This is quit interesting project, I'm loving its direction. Something I hoped for long time ago. I like that it's trying to make a better C not eliminating it. Will keep a close eye.