JSON null evades `is nothing`: Value::Null and Value::Nothing are crossed and never compare equal

[logbie]

Summary

WFL has two internal "no value" variants — Value::Null and Value::Nothing — and they are crossed:

• the nothing literal evaluates to Value::Null (typeof reports "Null"), and x is nothing matches it;
• parse_json maps a JSON null to Value::Nothing (typeof reports "Nothing"), and x is nothing does not match it.

Because PartialEq for Value short-circuits on std::mem::discriminant, the two variants never compare equal, so the natural guard check if x is nothing: silently passes JSON nulls through. The isnothing native has the opposite bias (matches only Value::Null), so it also misses parse_json nulls.

Reproduction

store payload as parse_json of "{\"k\":null}"
store v as payload["k"]
display "json-null typeof: " with typeof of v
check if v is nothing:
    display "json-null is-nothing: yes"
otherwise:
    display "json-null is-nothing: no"
end check

store w as nothing
display "literal typeof: " with typeof of w
check if w is nothing:
    display "literal is-nothing: yes"
otherwise:
    display "literal is-nothing: no"
end check

Observed (release build of current main):

json-null typeof: Nothing
json-null is-nothing: no
literal typeof: Null
literal is-nothing: yes

Expected: both branches say yes — a beginner writing check if v is nothing: after parse_json is expressing exactly this intent.

Where the pieces sit

• src/stdlib/json.rs — serde_json::Value::Null => Value::Nothing on parse; both variants serialize back to JSON null.
• src/interpreter/value.rs — impl PartialEq for Value returns false for mismatched discriminants, so Null == Nothing is false; type_name() reports them as two different types ("Null" / "Nothing").
• src/stdlib/core.rs — native_isnothing matches only Value::Null.
• The nothing literal evaluates to Value::Null.

Impact

Real-world hit: a web handler that reads fields from a client JSON payload and guards them with is nothing lets {"api_key": null} straight through — in our case the null then reached an HTTP-client native and produced Expected text, got Nothing at runtime (line 0, column 0, so the failure doesn't even point back at user code). Untrusted-input validation is exactly where this guard gets written, which makes the silent pass-through worse than a crash at the check itself.

Workaround we're shipping in the app: type-based guards, e.g. check if typeof of model_id is not equal to "Text": — which catches both variants but is not the form a beginner would reach for first.

Suggested direction

Whatever the internal representation, the user-visible semantics should collapse to one concept:

1. is nothing (and is not nothing) treat Value::Null and Value::Nothing as equal — likely in the equality path, with a special case ahead of the discriminant short-circuit.
2. isnothing native matches both.
3. typeof reports one name for both (today it leaks two internal names, and the names are swapped relative to intuition: the nothing literal reports "Null").

Happy to follow up with a failing-test PR (Red first, per testing.md) if that helps — the repro above drops straight into a TestPrograms/ case plus a unit test on Value equality.

Found while dogfooding WFL as the backend for a chat app (LogbieLLC/Rin app/server.wfl), same series as #647 and #648.

[logbie]

Triage: partially fixed on main already — items 1 and 2 landed in #652, item 3 is still open and is now the whole issue.

Verified against main at 69c1c1e (v26.7.53). PR #652 ("Codex/typechecker contract audit", merged 2026-07-27T04:38Z, ~12h after you filed this) implemented two of your three suggestions:

1. Equality — done. src/interpreter/value.rs:602-607 now special-cases the pair ahead of the discriminant short-circuit, exactly as proposed:

   if matches!((self, other),
       (Value::Null, Value::Nothing) | (Value::Nothing, Value::Null)) {
       return true;
   }

   The nothing literal still evaluates to Value::Null (src/interpreter/mod.rs:12626, :13263), so check if v is nothing: routes through this path and should now match a parse_json null.
2. isnothing — done. src/stdlib/core.rs:29-32 is now Value::Null | Value::Nothing => true, with a unit test (isnothing_accepts_both_legacy_no_value_variants).
3. typeof — NOT done, and deliberately pinned. src/interpreter/value.rs:248-249 still reports "Null" / "Nothing" separately, and src/stdlib/json.rs:175-180 carries a test that actively locks the divergence: "JSON null must preserve the legacy Nothing variant for typeof". So this is a conscious back-compat decision, not an oversight — unifying it means retiring that assertion.

Two things worth acting on:

• The repro is unguarded. The only new coverage is the native_isnothing unit test. Nothing exercises the is nothing operator against a parse_json null, and TestPrograms/ has no null/nothing case at all. Your repro should drop in as a TestPrograms/ program plus a Value equality unit test — otherwise Codex/typechecker contract audit #652's fix is one refactor away from silently regressing, with no red test to catch it.
• The naming inversion you flagged is the real remaining sharp edge. The nothing literal reporting "Null" while JSON null reports "Nothing" is backwards from intuition either way round. Since your shipped workaround is typeof of x is not equal to "Text", this is the surface app code is actually leaning on today. Worth deciding: collapse both to one user-visible name ("Nothing"), keep the two internal variants, and update the json.rs assertion to pin the unified name instead.

Suggested triage: retitle/rescope to the typeof unification only, or close and open a focused follow-up — the equality half is resolved. Happy to see the failing-test PR you offered; it is still the missing piece.

Posted by the WFL repo warden (automated triage pass).