C# nullable reference types answer an important question: may this property have no value?
They do not answer a different data-access question: was this property loaded at all?
For a partially selected entity, string? Name == null can mean either SQL NULL
or “the query never selected Name.” TeaQL's generated .NET E expressions model
those as separate states and preserve the distinction through ADO.NET mapping.
Go programmers are comfortable with the comma-ok idiom:
value, ok := lookup(key)
That shape is useful for an E expression too, but one boolean cannot explain why a value is absent. In data-access code, there is a critical difference between a loaded null-like value and a field the query never selected.
TeaQL's generated Go E expressions preserve three states and provide two
evaluation styles: TryEval() for explicit error handling and Eval() for
strict fail-fast business logic.
Java applications have spent decades improving null handling, yet one dangerous ambiguity remains common in data-access code:
Does
nullmean the database value is NULL, or does it mean the query never loaded the property?
Those two states have completely different business meanings. Treating both as
null can make a test pass and let the wrong decision reach production.
TeaQL's generated Java E expressions now preserve three states: Value, Null, and NotLoaded. A missing preload becomes a structured exception at the point of use, while a genuine SQL NULL remains a legitimate null value.
Python makes absence easy to express. A database NULL, a missing JSON key, an
empty relation, and an optional function result can all become None.
That convenience becomes dangerous for partially loaded entities. If a query
did not select task.name, returning None tells business code something the
runtime does not know.
TeaQL's generated Python E expressions keep Value, Null, and
NotLoaded separate. Loaded nulls evaluate to None; unselected fields raise
a structured TeaQLNotLoadedError.
Rust's Option<T> is one of the language's best tools. It forces absence into
the type system and eliminates an entire class of null-pointer failures.
But an ORM or data runtime has another state that Option<T> cannot express on
its own: the field was not loaded.
If both SQL NULL and an unselected column become None, business logic cannot
tell a legitimate absence from an incomplete query. TeaQL Rust models the
missing state explicitly with EvalResult::Value, EvalResult::Null, and
EvalResult::NotLoaded.
TypeScript can describe optional data precisely at compile time, but JavaScript
still has several runtime forms of absence: undefined, null, a missing object
key, and an empty collection.
For database-backed models, a missing key has another possible meaning: the query did not select the field.
TeaQL's generated TypeScript E expressions preserve Value, Null, and
NotLoaded so that undefined does not silently stand in for an incomplete
query plan.
In the evolution of TeaQL, we've constantly navigated the tension between developer ergonomics and idiomatic Rust. We recently brought the E:: fluent expression chain back to Rust.
This is not a simple rollback. The new design uses reference chaining instead of cloning entity graphs and emits structured diagnostics when a relation was not loaded.