Devlog: Formalizing Flower’s Null Foundation

Flower already had some of the pieces for null, but they were a bit scattered. The goal here was to make it explicit, consistent, and safe before moving on to nullable syntax like ?T or full union-based nullability later in v1.4.

Another shorter devlog, but still important and distinct enough for me to think “Hmm devlog time? Yes, devlog time!”

What changed

The main work was in typechecking. I added to the compiler’s idea of what null is, how it is represented internally, and what kinds of values are actually allowed to accept it. Rather than letting null-related behavior stay implicit across a few checks, null now follows a clearer rule set:

• null has one centralized internal type representation
• pointer-like values can explicitly accept null
• null comparisons and assignments now go through the same semantic path

Why this matters

This isn’t all that important on its own, but it matters a lot for where Flower is going next.

If null is not defined well, then later features like:

• ?T
• better unions
• smarter narrowing
• more expressive type flow

all become more error-prone (or so I assume given my track record) than I want need them to be.

Validation

I also expanded the example coverage so null: it now has dedicated behavior checks around assignment, passing values around, and comparison behavior.