v1.4.4 Devlog: Giving Flower Real Semantic Union Types

I made it so that semantic unions are now in Flower’s parser and type system — but not yet its codegen.

The goal was to support types like:

value: int | string
next: @Node | null
type Result = int | string

What’s new

The parser now understands | inside type positions and builds semantic union type information instead of relying on those old plain aliases or backend-shaped hacks.

On the typecheck side, unions are now carried through normal type copying and alias resolution. That means named aliases like:

type MaybeName = string | null

make sense after resolution, instead of collapsing into nonsense.

The typechecker also now accepts union-compatible usage in the places that matter for a foundation:

variable initialization
assignment
parameter passing
return checking
alias resolution

So if a value matches one union member, it is accepted. This is sorta implicit behavior, but I think it gets a pass due to its somewhat explicit nature?

What it does not do yet

This version was intentionally strict about using unions as values.

You cannot yet directly:

index a semantic union
access a field on a semantic union
use arithmetic / comparison operators on one
print one directly

Instead, Flower now requires an explicit cast before using a union value that way.

That may sound harsh, but it is the right restriction.. for now. There is not any narrowing yet, so pretending unions were fully usable would just make the language lie and spit out 2,000 errors.

Where this leaves v1.4

Flower now has:

transparent type aliases
null as a real type-system concept
pointer-first nullable types
semantic union type representation

The next step is the part that will make unions actually usable rather than merely legal:

narrowing with is
better explicit extraction with as
eventually making ?T truly become T | null instead of remaining pointer-first for now

No fun screenshot this time :p just frontend work for now…

Ivy, signing off <3