HACKER Q&A
📣 Nuoji

Help me improve my C-like language, C3


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.

The site here has an overview of the language and code samples: http://www.c3-lang.org

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

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.

The syntax tries to stay true to C, with things added on top that C can't easily add due to backwards compatibility:

- Module system

- Generics

- Semantic Macros

- Error handling

- Defer

- Value methods

- Associated enum data

- Subtypes (Go's embedded structs)

- Optional contracts

- Built-in strings, maps, subarrays and vararrays

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

  👤 qppo Accepted Answer ✓
Here are the things I would need to migrate from C/C++/Rust to a new language:

    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.
Syntax/semantics of the language are significantly less important to me than all of the above.
👤 gus_massa 

  /**
   * @ensure const(foo), const(bar.x)
   **/
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:

  #ensure const(foo), const(bar.x)
or

  @ensure const(foo), const(bar.x)
👤 zzo38computer
I might like to have, in a better version of C:

- GNU extensions, such as zero-length arrays, ?: with nothing in between, and statements inside of expressions

- Less confusing syntax for types

- Full LLVM features

- Non-Unicode

- Both normal include files and token macros, as well as namespacing and hygienic macros supported too

- Standard macros for testing alignment, endianness, etc

- Macros that can call compile-time execution of codes which can deal with the AST

- Reduced runtime requirements

- 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

- The goto command.

The worst thing about C is I think the confusing syntax for types. Pointer arithmetic and goto are both good, though, so keep those.

I can do without automatic memory management.

👤 allochi
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.