Null safety in Rune

[waywardgeek]

One of the valid gripes about Rune on Y-Combinator was the lack of null safety in a modern language. This will be corrected, either in the C version of the Rune compiler, or in the bootstrap where we're rewriting Rune in Rune.

Null needs to become a bit in the datatype, just like secret is today. In most cases, Rune code does not declare a type in a variable assignment, but type constraints are optional. With type constraints, you can write:

human: Human = Human(name, mother, father)

In future Rune, Human will mean not-null, which is the case when calling a constructor. For the case where it can be null, we could write the type constraint as:

child: Human? = father.firstFatheredHuman

In most places where null can occur, generated code will deal with it. Iterators, for example, should not yield null. In places where the user knows null can no longer occur, a new type cast will be available: expression!. For example, if child can be null, we can write code like:

child: Human = father.firstFatheredChild
if !isnull(child) {
    processChild(child!)
}

Keeping track of null like this will improve speed in Rune, when compiling in the default mode of full memory safety. Today, we generate range checks for every array access. Because Rune uses SoA memory layout, guess what? We do the range check currently for every property access of every object. In Rune, null is not 0. It is the largest integer representable with the reference type for the class, typically 0xffffffffu32. We verify an object is non-null with the range check, before indexing into an array representing one data member of a class.

Because non-null types do not require the range check, null safety will improve performance.

[waywardgeek]

I made good progress adding null safety to Rune. It should be available in a few days.

[waywardgeek]

And it's done.