But a lookup that can both fail and find nothing is common enough:

// the DB may be down (Error), or the key may be absent (None)
func Find(key: string) !?Record

Let's see what it takes to support !?T without giving up on simplicity.

The obvious options

1. Treat "not found" as an Error and return !T. This is what Go does with sql.ErrNoRows and fs.ErrNotExist. "No value" becomes a special error, and callers have to compare error values to tell the two apart. But "no value" is an expected outcome, not an error, and the type signature should indicate this. It also means try propagates "not found" up the stack as if something went wrong.
2. Keep the layers, as Zig does: !?T is an error wrapping an optional, unwrapped one layer at a time. It works, but every caller has to unwrap twice, and ?!T ends up being a different type from !?T, which violates the "Union Types are sets" approach.

Tempting option 3: Derive None from Error

If None is a subtype of Error, then ?T is implicitly convertible to !T, and T | None | Error is the same as T | Error. In other words, !?T is just !T. We get a simple chain T <: ?T <: !T, and the nesting problem goes away without any new types.

There are many benefits to this approach:

• Find simply returns !T, and "not found" is none, which is now a valid Error value. The caller checks if r := Find(key) {} else if r is None {} else { log(r) }.
• The boolean context rule becomes simpler: a value is falsy if it is false or Error, and truthy otherwise.
• Changing a return type from !T to ?T is now a narrowing, so it passes the Litmus Test from the previous post.
• try needs no extra rules: try on ?T works inside functions returning ?U or !U, and try on !T only inside functions returning !U.

But there is one problem, and it is a big one: none becomes an error without any context. var f: !File = none compiles, and log(f) has nothing useful to print. Worse, try m.Get(key) inside a function returning !Config propagates none to the caller instead of saying which key was missing, and nothing in the type system reminds you to do better.

This is not a theoretical concern. Rust tried exactly this: std::option::NoneError on nightly allowed ? to convert an Option into a Result, and it was removed for this very reason. Zig requires an explicit conversion instead: orelse error.NotFound. And Go's io.EOF is the same idea in practice: an "error" that is really an expected absence, with if err == io.EOF checks everywhere.

More fundamentally, half of the argument in the Go post was that the absence of a result is not an error. Making None an Error gives that up for !T. We want None and Error to remain distinct types, so the compiler knows which one we meant.

Better option: Sealed Common Base

Instead, let's derive both None and Error from a common base type Failure:

sealed type Failure = None | Error

Failure is sealed, i.e., None and Error are its only subtypes. Now the Union Type algebra does the rest:

• ??T is the same as ?T, because T | None | None is T | None
• !!T is the same as !T, because T | Error | Error is T | Error
• !?T is the same as ?!T, because both are T | None | Error, which is T | Failure

Nesting flattens, the order does not matter, and !?T is the only new type. We still have just two primitive kinds of Union Types, and nesting them produces the third one. Let's use !?T as the canonical spelling.

Conversions

Every type is implicitly convertible to the types below it, but not the other way around:

Error  T  None
   | /   \ |
   !T     ?T
     \   /
      !?T

In code:

var rec : Record
var r : !?Record = rec        // T to !?T
    r = none                  // None to !?T
    r = Err("DB is down")     // Error to !?T
var m : ?Record = rec
    r = m                     // ?T to !?T
var e : !Record = rec
    r = e                     // !T to !?T

e = m                         // rejected: ?T is not convertible to !T
m = e                         // rejected: !T is not convertible to ?T

The last two lines are the whole point of not going with option 3: None and Error remain distinct, and the compiler will enforce it.

Boolean context and narrowing

The rule from the previous post actually becomes simpler: a value is falsy if it is false or a Failure, and truthy otherwise.

Narrowing works the same way: in the else branch !?T is narrowed to Failure, and one more type check tells None and Error apart:

if r := Find("bob") {
    // r is Record here
    r.Greet()
} else if r is None {
    // r is None here
    CreateUser("bob")
} else {
    // r is Error here
    log(r)
}

For comparison, Zig needs both catch and orelse for the same thing.

try and !?T

The try prefix from the previous post needs no new rules. It returns the failure to the caller, so the failure must be convertible to the return type of the enclosing function:

Converting between kinds has to be explicit:

func LoadUser(key: string) !User {
    r := try Find(key)            // rejected: Find may return None, LoadUser cannot
    r := try Find(key) ?? Err("user not found: " + key) // OK: None replaced by an Error
    return User(r)
}

With option 3 the first line would have compiled, and the caller would have received an error saying nothing.

Litmus Test

Let's run the same test as in the previous post: which signature changes do not break the callers?

Extending Inputs

Changing a parameter type from ?int to !?int is a widening, so old callers passing an int or none still work. Whether a function should ever accept an Error as input is a separate question, but the type system does not need to forbid it.

Test passed!

Restricting Outputs

!?T can be narrowed in two directions: to !T or to ?T, and then further to T. Both paths are backward compatible, same as before.

Case 1: !?T -> !T, no more none. Suppose we've learned how to never return none from Find:

// v1
func Find(key: string) !?Record
// v2: never returns none
func Find(key: string) !Record

// old callers still work, even though the none branch is dead now
if r := Find("bob") {
    r.Greet()
} else if r is None {
    CreateUser("bob")
} else {
    log(r)
}

Test passed! Note that in the dead else if branch r is of type Error, so r is None is always false. Perhaps the compiler generates an "always false" warning, similar to the "always true" warning in the previous post.

Case 2: !?T -> ?T, no more errors. Now suppose instead that Find never has to return errors anymore:

// v1
func Find(key: string) !?Record
// v2: never returns an Error
func Find(key: string) ?Record

// old callers still work, even though the error branch is dead now
if r := Find("bob") {
    r.Greet()
} else if r is None {
    CreateUser("bob")
} else {
    log(r) // dead: r is Failure but not None, and Error is impossible
}

Test passed! Here the compiler is less likely to notice the dead else branch, since else has no condition to evaluate. It also does not change anything for try: try Find(key) inside a function returning !U was rejected before (Find could return none) and is still rejected after.

Changing !T to ?T or back is neither a narrowing nor a widening, so it is a breaking change. And it should be: it changes the meaning of the function, and the compiler should say so.

What does it cost?

• A third type. It is derived rather than declared, but it exists, and !?T will show up in function signatures.
• Two-step narrowing. Telling None from Error takes a second if. Zig has the same cost.

Conclusion

In Why Go-style error handling is not great we've called a function partial if it is unable to produce a return value for all possible inputs. T | Failure is exactly that: either a value, or the reason there is none. ?T and !T cover the two possible reasons, and !?T covers both.

Two primitive Union Types and one sealed base type are all it takes to support nesting.

• Why Go-style error handling is not great
• Why TypeScript and Crystal have the best Union Types

But what can we do without going all the way to full-blown Union Types? What if we don't need to represent types like int | string and are willing to limit our needs to optional values and the possibility of functions failing?

Let's take our inspiration from Zig, which already does almost exactly this, and use the same ?T and !T notation. However, we won't follow Zig 1:1. Also note that Kotlin, Swift, Dart, and C# have the ?T half written as T?.

It's worth spelling out what exactly makes it work, and what it takes to pass the API evolution Litmus Test at the end.

1: Limited Union Types

The basic idea is to introduce just two possible kinds of Union Types:

1. For a type T, ?T means T | None.
2. For a type T, !T means T | Error. Here Error is assumed to be a single interface type, like Go's error, i.e., no typed errors.

Corollaries:

1. It follows from #1 above that ??T and ?T are the same type because T | None | None is T | None.
2. The desire to have just two Union Types precludes ?!T/!?T: it would mean T | None | Error, and we strive for simplicity (but wait till you read the next post).

Very importantly, the following pseudocode should be accepted by the compiler (this implicit conversion is what Maybe/Result wrappers lack, and what makes the Litmus Test below pass):

var x : string
var maybe_x : ?string = x // implicit T to ?T conversion
    maybe_x = none        // implicit None to ?T conversion
var error_x : !string = x // implicit T to !T conversion
    error_x = Err("Nope") // implicit Error to !T conversion

And the following should still be rejected:

x = maybe_x // ?T is not convertible to T
x = error_x // !T is not convertible to T

In other words, T is a proper subtype of ?T and !T.

2: Extending boolean context

In a boolean context, e.g., inside an if condition:

1. ?T is truthy if it is T and falsy if it is None
2. !T is truthy if it is T and falsy if it is Error

3: Control-Flow-Sensitive typing

TypeScript calls it Type Narrowing, Crystal — Type Restriction, and Scala — Flow Typing. But the idea is the same: at compile time, a variable's type becomes more precise depending on code flow.

In our case, a variable of type ?T or !T can be narrowed to type T, and to None/Error in the else branch.

Examples combining it all together

An iterator returning the next element:

func Next() ?T

for val := Next() {
    // even though Next returns ?T, here val has the type T
}

Opening a file:

func Open(name: string) !File

if f := Open("test") {
    // f is of type File here, not !File
    f.Read(...)
} else {
    // f is of type Error here
    log(f)
}

Function signature evolution Litmus Test

This is the same test that Maybe/Result wrappers fail in Why TypeScript and Crystal have the best Union Types.

Imagine v1 of our library had a function:

func f(x: int) ?string

Now we are going to publish v2 of this lib. What can we do to this interface without breaking the callers?

Extending Inputs

A function is backward compatible if it can accept a wider range of inputs than before. Suppose we've learned to do something useful in our function without x, and we'd like to make x optional. Can we change the type of x to ?int?

func f(x: ?int) ?string

// old callers still work
f(3)

// but now this is possible too
f(none)

Test passed!

Restricting Outputs

A function is backward compatible if it returns a narrower range of outputs than before. Suppose we've learned a way to always return a meaningful string from f, and it does not have to be optional anymore, as we never return none. Can we change the return type to string?

func f(x: int) string

// old callers still work, even though the else branch is dead now
// perhaps the compiler generates an "always true" warning
if s := f(3) {
    s.ToUpper()
} else {
    UseDefault()
}

// but new callers don't have to check anymore:
f(3).ToUpper()

Test almost passed: we need to define how values of regular types (like string here) are evaluated in a boolean context. A simple rule could be: everything is truthy, except bool false, None, and Error. However, there are wrinkles when narrowing functions returning bool. Going from returning ?bool to bool changes the semantics for older callers: they would take the "no value" branch when false is returned. But that's an acceptable limitation — we just postulate that such an interface change is not backward compatible; don't do it.

Error Handling Ergonomics

Two more things are needed in practice, and both are orthogonal to the type system.

Error Propagation Syntactic Sugar

Since Error converts implicitly to any !T, passing an error up the stack already works:

func Load(name: string) !Config {
    if f := Open(name) {
        return Parse(f)
    } else {
        return f // f is Error here
    }
}

But as Yogi Berra said, "It's déjà vu all over again". It's not that different from Go's if err != nil { return err }.

A try prefix (as in Zig) or a ? postfix (as in Rust) that returns the Error to the caller, and otherwise narrows to T, removes the boilerplate.

With a try prefix:

func Load(name: string) !Config {
    f := try Open(name) // f is File here; if Open returns an Error, Load returns it as-is right away
    return Parse(f)
}

or with a ? postfix and no local variable:

func Load(name: string) !Config {
    return Parse(Open(name)?)
}

Similarly, supplying a default value for ?T can be done with a ??/orelse operator or an OrElse method.

func Get(i: int) ?int

a := Get(3) ?? 10
b := Get(3).OrElse(10)

Enforcing Error Checking

Discarding a !T value should be a compile error, as it is in Zig:

Open("test") // error: result of type !File is ignored

Conclusion

The results shown in the Examples and in the Litmus Test are not surprising — we expect this from proper Union Types, both in theory and as demonstrated by multiple languages supporting them.

Limiting Union Types to just two special cases is what makes the implementation of this feature much simpler, and perhaps tractable even for a new, quickly growing and evolving group of "systems programming languages".

Go-style error handling violates this principle. Let's see how.

Why bother?

Go is a well-established language, and despite overwhelming user feedback, even the core team gave up on improving error handling after multiple attempts (although they were mostly considering syntactic sugar to address endless if err != nil). Am I really hoping to suggest a change that is going to be implemented in Go?

No, and it's not the goal here. The goal is to learn from Go, and to stop repeating its mistakes, because many brand-new "systems programming languages" are replicating Go's approach, and it's a shame (at least from my perspective).

How Go deals with partial functions

A function is called partial if it is unable to produce a return value for all possible inputs. Then the question is: how does it indicate to the caller that the value was not produced?

Go has 2 standard patterns for dealing with such situations.

Absence of a result

Getting the map value and checking if the map contains a key in one call needs a way to indicate both "here is the value" and "key not found". Go's way of dealing with such cases is returning a tuple, where the second bool value indicates success/failure:

val, ok := m["key"]
if !ok { ... key not found }

Error performing an operation

Opening a file could fail for many reasons. So, in addition to the file handle, Go prescribes returning an error value, where nil indicates "no error":

file, err := os.Open("example.txt")
if err != nil { ... failed with err }

What's wrong with this approach?

In both cases the language allows you to express more cases than actually needed/desired. We'd like to express just 2 possible outcomes:

• key found, here is the value / key not found
• file opened, here is the handle / here is a specific error why the file cannot be opened

But mechanically a 2x2 matrix of 4 outcomes can be expressed, where 1 case makes no sense, and often 2 cases:

It brings unnecessary questions, like:

// which one is better?
// (1) defer first:
file, err := os.Open("example.txt")
defer file.Close()
if err != nil { ... failed with err }

// or (2) check error first
file, err := os.Open("example.txt")
if err != nil { ... handle err }
defer file.Close()

Go prescribes (2) to be used, but it means a function returning both a file handle and an error will leak handles. Sure, it's a bug in that function, but that's exactly the point here: if it were impossible to express, this class of bugs would not exist.

Nothing forces you to check

Both patterns are conventions, not rules. The language happily lets you skip the check:

val := m["key"]          // key absent? val is 0, no error, no warning
f, _ := os.Open("x.txt") // compiles clean, f is nil on failure

Go complains about unused variables, never about unused results. That is why errcheck exists.

Can we do better?

With the introduction of generics, Go can follow many other programming languages by using Maybe[T] for the first case and Result[T] (implying failure type is always error) for the second.

There are 2 improvements here:

1. Invalid state cannot be expressed. That's correct by construction.

2. Value must be unwrapped before it can be used, so no forgetting to check for errors:

   // assume m is map[string]int
   val := m["key"] // val's type is Maybe[int]
   x := val + 1 // would not compile, val is not an int
   

   file := os.Open("example.txt") // file's type is Result[*os.File]
   file.Read(buffer) // would not compile, file is not an *os.File
   

Is this the best we can do?

In Go — perhaps, but in general no, we can do better. And I've covered it before: Why TypeScript and Crystal have the best Union Types.

However, there is also a middle ground: not quite full Union Types, but still better than Maybe/Result. This is the subject of the next post.

Notes

1. Also known as "make illegal states unrepresentable", a phrase coined by Yaron Minsky in Effective ML Revisited (2011).
2. Go's io.Reader contract does this on purpose: it allows Read to return n > 0, io.EOF. And callers must process the bytes before looking at the error. This is beyond good and evil, this is just diabolical.