May 29

https://c3-lang.org/language-common/optionals-advanced/
The language is quite nice, resembles BetterC, but also the first ergonomic language where I see the Result type in action. Result is also used for nullable types.

// Function returning an Optional
fn int? maybe_func() { /* ... */ }

fn void? test()
{
	// ❌ This will be a compile error
	// maybe_function() returns an Optional
	// and 'bar' is not declared Optional:
	// int bar = maybe_function();

	int bar = maybe_function()!;
	// ✅ The above is equivalent to:
	// int? temp = maybe_function();
	// if (catch excuse = temp) return excuse?;

	// Now temp is unwrapped to a non-Optional
	int bar = temp; // ✅ This is OK
}

But striving to be evolution of C, faults look like error code singletons and apparently don't carry much information.

May 29
On 5/29/25 1:18 PM, Kagamin wrote:

> But striving to be evolution of C, faults look like error code
> singletons and apparently don't carry much information.

Same here.

I've been using a macro system in a C++ library that exposes a C API. All implementation functions return an optional type that automatically errors if not checked. Equivalents of enforce(), assert(), etc. automatically return an invalid optional.

Here is your point: There is a constant-length buffer that collects a backlog of error messages from function calls. Exhausting the buffer is not an error; the lowest-level error messages are retained. That buffer is just 4K, which is 0 bytes to my eyes :).

The caller of the C API receives a C array of error strings that they can print to see exactly what happened. Sweet...

Oh... oh... and all formatted error messages are actually generated in a development build even when there are no errors, to prove that error messages will render and look correct when generated. (The buffer is a lot larger in that case, not 4K.) Very sweet indeed... :)

Ali