0.7.0 was supposed to be THE big change this year, but 0.7.1 is actually quitely introducing some very important features.

Operator overloading

Operator overloading is the biggest change of course, which is already covered in great detail here. The @operator, @operator_s and @operator_r attributes are used to enable overloading for user defined types.

More static checking

An important step towards correctness is that @require contracts for functions are now inlined at the caller site for safe mode. This has always been a thing for macros, but now this works for functions as well. This means simple errors, such as using a null pointer where it wasn't allowed or passing a zero where the argument:

<*
 @require a > 0 : "The parameter cannot be zero"
*>
fn void test(int a)
{ ... }

fn void main()
{
	test(0); // Compile time error: contract violation "The parameter canno

Operator overloading is a divisive feature. It's been used for atrocious hacks, and to make code totally unreadable, but it's also the reason people stick to a C-like subset of C++ rather than using plain C for projects.

C3 has had operator overloading for a long time, but only for array indexing. In fact there are four different overloads: len [] []= and &[]. Together they do not only enable indexing, but more importantly they enable foreach.

If a type implements len and at least one of [] and &[], then you get foreach on that type. &[] is required for foreach with ref arguments though. And while you can use [] without implementing len, you need len for reverse indexing like a[^3].

However, I've resisted adding operator overloading for arithmetics and equals. Such a change brings us further away from C semantics than I've felt comfortable with. It can certainly be extremely misused and cause confusion.

But, as of 0.7.1 it's in the language. So

Initially I had planned 0.7.1 to be mostly patching 0.7.0, but plans change.

The big news is that operator overloading is coming. Not just the existing overload of [] &[] and []=, but arithmetics, bit operations and equals is all coming.

Comparisons is conspicuously missing, but might arrive.

Overloading is here to simplify creating numerical types that can be manipulated with the normal operators.

Consequently, there won't be anything like C++, where you can overload deref, dot invocation, casts etc. Also, overloads may not manipulate global state.

All in all, using these overloads for anything but numerical types is not intended (yes, so don't string concat with + nor should you use << to append to lists etc)

Operator overloading will only allowed on user defined types.

The 0.7.0 milestone reached

Originally I was going to write this as normal release notes, but it's a bit too much to go through the whys and wherefores of the changes. So the format of this blog post is going to be a bit different.

0.6.0 was tagged in June 2024, and since then there's been monthly releases up until the last one, 0.6.8. While the language has evolved during this year, each 0.6.x version has been backwards compatible with code written for previous 0.6 versions. Despite this constraint, there have been a lot of improvements, especially in enhancing compile time to have much fewer corners, and of course the standard library has been improved as well.

Well worth mentioning is the impact Tsoding (https://www.twitch.tv/tsoding) had on the visibility of the language. His "recreational programming" streams on C3 brought a lot of new users to the community, and with it a lot of extremely valuable feedback on both the langage and the standard library.

T

I occasionally get requests for aliasing modules in C3, so something like import foo::mylongname = ml;. Often the use case is to get a shorter prefix for their types, as they're doing foo::mylongname::MyType everywhere.

This is a fundamental misunderstanding of how you are supposed to organize code in C3.

The reason for mandatory module prefixing of functions and globals

In C, we typically have some name spacing scheme in place. For example one might have settings_parse_options(...) settings_print_help(...), settings_apply_options(...) and so on.

What C3 tries to do is to formalize this informal style using the last component of the module path:

import app::settings;

fn void something(String[] args)
{
    SettingOptions? options = settings::parse_options(args);
    if (catch options)
    {
        settings::print_help();
        os::exit(1);
    }
    ...
}

How to pick a good module name

This scheme puts a lot of responsi

Release 0.6.8

0.6.8 is to be the last release before 0.7.0 and had a short cycle of development - only two weeks. As usual it has fixes, but more importantly, it prepares for 0.7.0.

So let's dive into what's new in this release!

"New generics" - List{int}

0.6.8 has the flag --enable-new-generics, which implements the new syntax for generics, from, for example, List(<int>) a; to List{int} a;. With this flag the compound literal syntax of Foo { 1, 2 } is disallowed, instead it uses C-style (Foo) { 1, 2 }.

Expression blocks and @operator(construct) deprecated

The expression blocks {| |} helps you turn any sequence of statements into an expression. This would be immensely useful in C-like macros, but with semantic macros in C3 it's much less so, to the point that it's being removed in 0.7.0. The feature isn't bad, it just hasn't been useful enough to keep it.

The @operator(construct) which allowed static method-like invocations on types is

0.6.7 has been interesting. There has been some significant additions to the language that opens for new solutions. Also because it's now finally possible to manipulate compile time arrays in a simple way, there are some simple but useful compile time tricks that now is available. For example, string manipulation at compile time.

So let's have look at the biggest changes.

Compile time improvements

As previously mentioned, compile time arrays can now be mutated. This allows things like $arr[$i] = 123. And at this point, the only thing still not possible to mutate at compile time are struct fields.

In addition to this the concatenation operator, +++, now works on all types of arrays, even ones defined with gaps.

"Inline" enums

It's now possible to set enums to have its ordinal or an associated value marked "inline".

The feature allows an enum value to implicitly convert to that value:

enum Foo : int (inline String name, int y, int z)
{
  ABC = 

The 0.6.6 release is surprisingly on time despite (or perhaps thanks to?) the Christmas holidays. It's a new year, and this summer C3 will turn 6. By April, version 0.7.0 will be released, removing deprecated code. The plan is to have one "dot one" release each year until 1.0 is reached (and if everything goes according to plan, the version after 0.9 will be 1.0).

But let's dive into what's new in this release!

Enum from_ordinal / ordinal changes

A longstanding pain point with enums has been modeling C enums with "gaps," as in this example:

typedef enum
{
    ABC = 42,
    GHJ = 101
} MyEnum;

A workaround in C3 using associated values like this doesn't feel ideal:

enum MyEnum : (int val)
{
    ABC = 42,
    GHJ = 101
}

This is because you can get the ordinal of the enum with a cast, e.g., (int)MyEnum.ABC, whereas retrieving the an associated value requires access, like MyEnum.ABC.val.

There are some ideas to bridge this gap, b

Why doesn't C3 allow aliasing of namespaces? Wouldn't import raylib as rl; be a good idea? Why am I so hell-bent on not allowing it?

So, first off, C2 has aliasing. It offers three levels:

1. Importing with the full name.
2. Importing with an alias.
3. Folding the imports (so everything can be used without prefix)

Why didn't I keep this?

C2's flat module namespace

First off, it's important to realize that C2 has a flat module namespace. There are no std::core::mem submodules, everything is bundled up into fairly large groups of functions and types. For example the stdio module which would have all the io functions and so on.

My concern was that it would be very likely for libraries to collide if they were flat.

EVERYONE would want their particular name to be the name for something. So now you can't use library net from Foo, because you also want to use the library net from Bar.

Aliasing won't help you because import net as foonet only

0.6.5 is out, and it brings some improvements and a bunch of bug fixes.

Splat in initializers

Splat has gained more and more features the last releases, and this is likely the last one, allowing you to splat into initializers. This means something like this now works:

struct Foo { int a; int b; }

fn void test(int[2] x)
{
  Foo f = { ...x };
}

Improved [] overloading

Using list[i] *= 2; or list[i]++ where "list" was a type with subscript overloading (such as List) was not possible. This now works fine.

Improved Optionals

Previously using a++ where "a" was an optional, had required using the optional result. This is now no longer the case, and

int! a = foo();
a++;

Works fine.

Updated command line options

A "quiet" option using -q is now available to suppress all non-error output. Furthermore the --debug-log and --debug-stats have been replaced by -v, -vv and -vvv for increasing verbosity.

Finally 0.6.4 is out. This version has some very important improvements working with constant slices. It is also more permissive when it comes to working with generic types.

But perhaps the change which is the most obvious is the introduction of a new contract syntax using <* *>, away from the Javadoc-like /** */ which was hard to differentiate from comments.

Constant slices

Constant slices has gotten a lot of low in 0.6.4. Constant vectors can now convert into constant slices, and slicing arrays, bytes and constant slices are now compile time operations.

This also adds constant bytes to/from char[] conversions.

New contract syntax

The use of /** */ for declaring a doc/contract block has been around for a long time in C3.

Unfortunately it has a glaring problem: if you accidentally forget a * and write /* */ your docs are considered comments and are silently ignored. This is obviously very bad.

Another problem would be code where the

0.6.3 is out and brings some nice improvements and changes together with bug fixes and standard library additions.

Some highlights:

New named argument syntax

The old initializer list style named arguments (.arg = value) is deprecated and replaced by a arg: value syntax which feels more natural for function invocation. So foo(.some_arg = 23, .other_arg = b) should now be foo(some_arg: 23, other_arg: b). The old syntax will be removed in 0.7.

Slicing of compile time values

C3 now allows slicing of untyped lists and strings. The upcoming 0.6.4 will further support compile time slicing on all compile time arrays, but in 0.6.3 this is still somewhat limited.

Splat everywhere

Ever had an int array and wanted to unpack it into a function call? Now you can do that with ...:

int[2] x = some_call();
foo(...x); // Same as `foo(x[0], x[1]);`

Some limitations apply: when splatting a slice into a normal argument slots the slice length ne

The 0.6.2 release is here, and a lot has happened since 0.6.1.

Mainly it's that C3 has seen a lot of new users which have explored the corners of the compiler and also filed request for improvements.

Let's start with the language additions:

&&& and ||| operators

0.5.0 introduced the compile time $and and $or functions. These worked at compile time and would not even type check the right hand side if the left hand side was invalid. So for example $and(false, a < 1.0) would be accepted even if a wasn't in the current scope.

It felt like this feature should be more part of the language proper, so two new operators were added: &&& and ||| to replace $and and $or respectively.

They were chosen for being visually distinct. Other alternatives, such as $& were discarded for not being sufficiently easy to spot.

The +++ operator

Somewhat on trial is the +++ operator. Similar to &&& and ||| it replaces a compile time function – or

It's time to release 0.6.1. There's been a bit longer to the x.x.1 than for 0.5.0 -> 0.5.1, and as a result there are quite a bit of additions.

Additions first: $append (appending to a compile time array) and $concat (combining two compile time arrays) were added as well as some compile time string macros: @str_hash(...) (hash a string at compile time), @str_upper / @str_lower (convert a compile time string to upper / lower case) and @str_find (find a substring in a string at compile time).

An important addition is @unaligned_load and @unaliged_store for loading/storing data to unaligned pointers.

In general there has been some relaxation constraints for some features. Trailing bodies, for example, may now use all type of macro argument kinds, like type arguments, and compile time folding of constant structs and arrays now work in all cases.

The standard library hasn't seen many changes since 0.6.0, but there have been some small enhancements.

The full ch

It's been three months and finally version 0.6.0 is here!

C3 was on a monthly update cycle, so what happened to version 0.5.6? Actually the main branch contained a releasable 0.5.6 for the last two months, but I didn't release it. A release takes a bit of time updating everything and making announcements and so on, and I felt that maybe I should just release version 0.6.0 instead – rather than to push the relatively small 0.5.6.

But on the other hand I kept delaying 0.6.0, because I was looking for more breaking changes to add (recall that 0.5.x cannot introduce any breaking changes for 0.5 code, so 0.6.0 is where the breaking changes happen)

However, now 0.6.0 is stable enough, and there has lately been very little to backport into the 0.5.x branch. So it's time to do the 0.6.0 release.

Let's go through what happened since 0.5.5 first:

Updated enum syntax

Using enums with associated values now look more like defining C enums than Java enums:

// Old
enum

Alongside the removal of goto, having adding an fn in front of function declarations seems superfluous and an arbitrary deviation from C.

Originally, C3 inherited this from C2, which at the time used func (it later simplified it to fn).

In C2 the keyword simplified grammar and made the code easier to search. In C3 however, it also made macro and function declarations symmetric:

macro int foo(int a) { ... }
fn int bar(int b) { ... }

Furthermore, it gives a simple and readable look for defining function types and lambdas:

def Foo = fn int();
Foo lambda = fn int() { return 1; };
Foo lambda_short = fn () => 1;

Because fn starts a declaration, it's easy to search for it using regex as well, or have some simple tool extracting function names.

So those are all straight up usability reasons for fn.

But there is one more:

// Which one is C3 code?

fn void my_function(int a)
{
    return a * a;
}

voi

Another month and another C3 0.5.x release (read the 0.5.4 announcement here), grab it here: https://github.com/c3lang/c3c/releases/tag/v0.5.5. As work on 0.6.0 is underway, 0.5.5 contains much fewer language updates, and instead mostly contains bug fixes.

In other news, the C3 site has gotten a face-lift: https://c3-lang.org. It's still a work in progress with more extensive guides planned.

For 0.5.5 the biggest feature is the new @link attribute. It works similar to #pragma comment(lib, ...) supported by MSVC and Clang.

module std::os::macos::cf @link(env::DARWIN, "CoreFoundation.framework");

// Use of any functions in this module section
// will implicitly link the CoreFoundation framework

...

While library dependencies still can be specified in project and lib

It's been about one month since C3 0.5.3 (announcement) was released. Since then there has been quite a lot of non-breaking additions to the compiler and I'm happy to announce the release of 0.5.4 of the C3 programming language. (Grab the downloads here: https://github.com/c3lang/c3c/releases/tag/v0.5.4)

In terms of changes to the language, bitstructs have gotten some additional love, with == and != supported and bit operations on bitstructs are now folded at compile time for constant bitstructs.

Startup initialization / finalization for macOS got an overhaul and is now guaranteed to be ordered, despite the OS not supporting ordering. This finally made dynamic calls safe to use with init functions.

For the stdlib, memory functions are changing. The family of new functions are now zero initializing by default. The reason is subtle: with implicit zeroing of locals, it's natural to start a

An observation: I notice that by virtue of people being mostly anonymous, a curious effect occurs on programming discords (and by extension elsewhere):

People who are "chat savvy" (or whatever we should call being good at writing in a way that is similar to being good at social interactions in real life) are able to dominate discussions by virtue of this.

In addition, people tend to "cluster" when it comes to opinions, so that followers of such persons may sway others ("everyone else agrees on this").

However, such savvy has nothing to do with actual programming skill or knowledge. Many of these "leaders" are in fact fairly inexperienced, if not outright beginners. Age is similarly obfuscated, so that teenagers might be seen as old and middle-aged persons may be taken for teenagers.

The most obvious example when someone new comes to a Discord and enthusiastically starts presenting ideas. If these ideas are not "approved" by the leaders, the person might immediately be mocke

LLVM used to be hailed as a great thing, but with language projects such as Rust, Zig and others complaining it's bad and slow and they're moving away from it – how bad is LLVM really?

What is LLVM?

LLVM of today is not just a compiler backend, it's a whole toolchain, and the project also provides a linker (lld), a C compiler available as a library (Clang) and much more.

Except for the anomaly of Zig (Zig also uses the entire Clang as a library), most language projects simply use the LLVM backend, and possibly also the lld linker.

LLVM, Clang, lld and most other parts of the project are written in C++, with a C API available for LLVM, but not for most of the other libraries.

The speed problem

When Clang was released, a selling point was that it compiled faster than GCC. Since then this has slipped a bit and GCC and Clang is about equally slow.

The problem is not in optimized builds - most people accept that optimized builds will compile slowly. No, the prob