Devlog: Adding Pointer-First Nullable Types to Flower

I worked on giving Flower its first real nullable type surface without
being overambitious and pretending the compiler is ready for full
optional-everything semantics yet.

The new syntax now works like this:

ptr: ?@int = null
text: ?@char = null

That means there is now an explicit way to say “this pointer-like value
may be absent,” instead of relying entirely on raw pointer habits from C
(If you couldn’t tell by now, I despise C).

What changed

The main work was split across lexer, parser, and typecheck.

I added:

• ? as a type marker in type positions
• is_nullable tracking in TypeInfo
• type rules for nullable pointer/reference values
• explicit compatibility for:
  • assigning null into nullable pointer-like types
  • comparing nullable values against null
  • casting between @T and ?@T

I also kept the scope intentionally narrow: this implementation is
pointer-first nullable support, not full nullable scalars.

So ?@int makes sense right now, but ?int is still deferred until I
make a better semantic union / optional representation for plain values.

Why this matters

It would have been easy to overreach here and claim “nullable types are
done,” but that would have been a big phat lie.

Pointer-like nullability lowers naturally enough with the current
backend and current compiler model. Scalar nullability, however, does
not. Once you let int or bool become nullable, you need a more real
representation for “has value / no value,” and that belongs in the later
union work, not here.

Result

• explicit absence
• compiler-owned semantics
• better future unions
• stronger type meaning without hidden magic

The next real step after this is not more patching around null — I
consider that done for now — but instead giving Flower the deeper
machinery needed for nullable non-pointer values and semantic unions
later in v1.4 so it doesn’t come back to bite me in my butt.