It's an interesting problem. Originally I experimented with both having `` and `&` syntax, so `int&` being a ref (non null) and `int` being a pointer. The thing you notice then are two things:

1. You want almost all pointer parameters non null.

2. Non-null variables is very hard to fit in a language without constructors.

Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as well. What you end up with is some period of time where a value is quasi valid - since non-null types need to be assigned and it's in a broken state before it's initially assigned.

It's certainly possible to create generic "type safe" non-null types in C3, but they are not baked into the language.

Nim solves this problem by only having two explicit, restricted nullable types: Pointers and references. Pointers are manually managed, references are automatically managed, both start as nil and must have their referenced objects instantiated manually.

The entire rest of the language is built on pass-by-value using stack values and stack-managed hidden unique pointers. You basically never actually need to use a ref or a pointer unless you're building an interface to a C or C++ library. I having written a 40k line production application with no reference or pointer types anywhere. Almost any case you'd need is covered by simply passing a compound type or dynamic container as a mutable value, where it's impossible to perform any kind of pointer or reference semantics on it. The lifetime is already managed, so semantically it's just a value.

I'm on the fence about function contracts like this. I've seen them for a decade in other languages, but never really used them, so I can't say how I feel about them.

But having them be inside comments is just weird.

Why is there only one way to solve a problem?

Is Zig really that common at this point that you'd feel comfortable using it for a work project? Its not just going to piss off the next person and have them need to rewrite it? I guess Rust has the same problem to some extent but there is a lot of resources for writing Rust out there now

I can only speak for myself:

1. It is so big.

2. It still largely depends on GC (less important actually)

It keeps adding features, but adding features isn't what makes a language worth using. In fact, that's one of the least attractive things about C++ as well.

So my guess:

1. It betted wrong on GC trying to compete with C++.

2. After failing to get traction, kept adding features to it – which felt a bit like there was some feature that would finally be the killer feature of the language.

3. Not understanding that the added features actually made it less attractive.

4. C++ then left the GC track completely and became a more low level alternative to, at which point D ended up in a weird position: neither high level enough to feel like a high level alternative, nor low level enough to compete with C++.

5. Finally: the fact that it's been around for so long and never taking off makes it even harder for it to take off because it's seen as a has-been.

Maybe Walter Bright should create a curated version of D with only the best features. But given how long it takes to create a language and a mature stdlib, that's WAY easier said than done.

There's also C4, but that's either an explosive or a notation language for modeling software architecture.

Yes, C3 started as a variant of C2.

Problem with Hare is that it is (or at least was last time I checked) Linux/Unix only and so by design. That kinda makes it DOA for many.

There's also Zig in the C-alternatives space.

https://ziglang.org/

C3 error handling is fairly novel though. It tries to find a sweet spot between composability, explicitness and C compatibility.

The try-catch has nice composability:

    try {
        int x = foo_may_fail();
        int y = bar_may_fail(x);
    } catch (... ) {
        ...
    }

Regular Result types need to use flatmap for this, and of course error codes or multiple returns also struggle with this. With C3:

    int? x = foo_may_fail();
    int? y = bar_may_fail(x);
    if (catch err = y) {
       ...
       return;
    }
    // y is implicitly unwrapped to "int" here

This is not to say it would satisfy you. But just to illustrate that it's a novel approach that goes beyond Optional and Either and has a lot in common with try-catch.

I honestly still don't know what `with` does in python. Without looking it up: Since I don't use python all that often, my best guess is that it calls some magic dunder function? I get that "primitives" like +, - aren't actually and ALSO call dunders, but there's a bit of "ssh don't tell me that and let me pretend" in the python ethos, and writing your own dunder function for anything that isn't number-ish is probably a huge code smell, and probably a potential footgun even if it is numberish. which is why `with` always felt weird to me.

Upvoted for humor.