Show HN: C3 – A C alternative that looks like C

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.

`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.

And RAII, that's just some syntax to make writing badly structured programs practical. Because it does the tedious parts of matching "parentheses", it allows you to use a lot of them, without consideration if you could refactor the program to get away with fewer of them.

RAII also comes at the cost of requiring or encouraging "features" like exceptions and all the good stuff like copy/move constructors and what not. All highly non-orthogonal language features that require lots and lots of special cases and extra boilerplate.

Hopefully just bytes, which trivially allows storage of UTF-8.

> built-in dynamic arrays, yess.

Dynamic arrays are only few lines to implement. There are different ways to do them, and no matter how, there will always be some problematic aspects. Not sure why you would want to choose one particular implementation and elevate it to a higher status.

> No preprocessor. Heck yes, it's a crutch.

It's ugly and inexperienced users will write bugs using it, but it's also tremendously useful. You mentioned quasiquoting as an alternative, but I'm not positive that it works as a preprocessor replacement for a language that lacks the "homomiconity" of LISP. Are there examples that show it works?

- A module isn't a file in C3 but that's a deep subject to get into.

- Automatic C header file import is something Zig is also touting as a feature. This was something I thought I would want early on. But as I worked myself through examples I find that it's hard to get right in all cases, which means that you'll run into cases where your language "almost" works. Plus now you actually tied your language not only to the C ABI, but the entire C standard (note how headers will for example contain static inline code that you will need to parse, or macros that define aliases of functions and builtins). That said a tool to automatically extract a "best effort" interface is planned.

- Regarding macros the difficulty has been to balance power with readability. So that is something which I am considering but still haven't quite embraced. Instead I have macros taking unevaluated expressions and you can in compile time get different things, e.g. `$offsetof("Foo", "a")` will give you the offset of the member `a` in the type `Foo`, but it's done through a special function rather than allowing straight up string interpolation. We'll see once the standard library work starts for real.

"Well, there's spam egg sausage and spam, that's not got much spam in it."

sorry, couldn't resist.

So far it seems a beautiful thing. Will take a deeper look and try to form an opinion. Great work!

- "Failables" (which is somewhat like Result) offers an alternative to error handling which mostly mirrors how one commonly does it in C, but with conveniences. Since it works a bit different from all other error systems, I'd have to point to the docs for a summary. :(

- Semantic macros where the big win is that they are easier to read and write. (This is heavily inspired by the ASTEC macro system for C)

- Generic modules, which works similar to macro-based generics in C, but easier to read and work with.

- Subarrays (slices), yes they make a huge difference even though they're an obvious addition.

- A bunch of GCC extensions

- Optional design by contract

There are no objects, and certainly no dynamic OO system. There are no constructors and destructors or similar explicit code.

Calling C is straightforward, you just need to declare that it exists, like you would in C.

So `extern func int printf(char*, ...)` -> now you can do `printf("Hello %s\n", "World");` the opposite also works, so if you define a function `func void foo() @extname("c3_foo")` you can then call it from C as `c3_foo()` (or skip the `@extname` but you would have to call `my_module_foo()` instead due to namespacing.

    No mandatory header files
    New semantic macro system
    Module based name spacing
    Subarrays (slices) and dynamic arrays built in
    Compile time reflection
    Enhanced compile time execution
    Generics based on generic modules
    "Result"-based zero overhead error handling
    Defer
    Value methods
    Associated enum data
    Built in strings
    No preprocessor
    Undefined behaviour trapped on debug by default
    Optional pre and post conditions

Apparently it has struct subtyping too.

Headers have some really unbeatable advantages over module interfaces: the tooling is incomparable plus the header serves as the API documentation.

While modules are great, in practice you have interop problems and you still need a tool (if it is a binary file) to extract the interfacing API.

Modules are better from an elegance and clean-design PoV, but headers win on the practicality.

The main motivation why it is nice to have it this way is that it's straightforward to understand what the type is when doing `&Point.add`. I have considered a `this` but it's not felt super important to have. Also, note that this is allowed: `Point *x = null; x.doSomething();` - this is made more obvious by taking the reference as an explicit parameter.

Maybe you don't mean to sound harsh but from their About page:

" It is an evolution of C enabling the same paradigms and retaining the same syntax as far as possible."

I don't think Zig has the same goal.

Also, they usefully compare the languages:

"In Zig but not in C3

    Pervasive compile time execution.
    Memory allocation failure is an error.
    Zig's compile time execution is the build system.
    Different syntax and behaviour compared to C.
    Structs define namespace.
    Async primitives built in.

    Module system
    Integrated build system
    Built-in strings, maps, vararrays
    Optional contracts
    Familiar C syntax and behaviour
"

I see that as a good thing. I’d much rather have a battle tested framework than everything being rewritten every 5 years in whatever is currently trendy simply because a new generation of developers are suffering from NIH (not invented here) syndrome.

I mean, yes C has its problems so I’m all for using safer languages, but just take a look at the mess that is front end web development and tell me that the alternative isn’t better.

I seriously hope languages like Rust do evolve into being much more than a fad. I’ve been in the industry a fair few years now and have seen languages fall in and out of favour (Pascal, Java, OCaml, Go, etc sure someone of them are still popular but nowhere near as much as when their respective hype machine was in town) and really what systems development really needs is another ‘C’ — as in a language that survives the next 50 years as a standard low level language that people can build solid operating systems from. Whatever language people want to code on top of that base is then fair game.

Zig is in many ways a more ambitious language. Not just in the language itself but in the tooling. Unlike C3 it has the ambition to "do things right" - often by doing things differently. Sometimes that pans out, but sometimes not. For example Zig adds a lot of UB "to be fast", but there's a particularly worrying intersection of (a) UB in overflow, (b) introduction of unsigned overflow and (c) implicit type widening which adds a lot of hidden UB / runtime aborts.

The simple example here is `a : i32 = b + c + d`. Even knowing that b, c and d fits in a short is not sufficient to guarantee this will not have UB. And even if we know that `b + c + d` does not trigger UB, we cannot guarantee that `b + d + c` does not have UB(!). The usual solution it to require explicit widening casts, but that solution seems hard for Zig due to relying on a lot of non-power-of-two types in the core language.

I guess also it's a matter of how much you think C sucks :D

I like C, and C3 is basically just trying to tweak a few things C can't change due to legacy reasons. It doesn't try to be a new "let's write everything from scratch because C is bad" kind of language, if you hate C then C3 isn't for you.