Type checker infers every user-defined action's return type as `Nothing`, causing spurious "Expected Text but found Nothing" at call sites

[logbie]

Summary

The type checker does not infer the return type of a user-defined action. A call result is treated as Nothing, so whenever that result is passed to a builtin position that expects Text — respond to req with …, open file at …, etc. — it prints a (non-fatal) error[ERROR]: … Expected Text but found Nothing, even though the value is Text at runtime and the program runs correctly.

This is the same family flagged as parenthetical "minor adjacent notes" in #557 and #558 ("the type checker doesn't infer an action's return type"); filing it standalone with an isolated repro since those were closed on their primary topics.

Environment

• wfl 26.7.8, Linux release build (cargo build --release)

Minimal reproduction

Even the simplest action — returning a plain concatenated string — triggers it:

define action called h with parameters name:
    store greeting as "hello "
    return greeting with name
end action

listen on port 8095 as s
wait for request comes in on s as req
store c as call h with "world"
respond to req with c and content_type "text/plain"

Running it prints:

Type checking warnings:
error[ERROR]: Response content must be text - Expected Text but found Nothing
    ┌─ repro.wfl:…
    │     respond to req with c and content_type "text/plain"

…yet the server responds hello world with 200. The error is emitted for the respond line because call h … is typed Nothing.

What is / isn't affected

• Inlining the value (no action) is fine: store c as read content from f then respond to req with c produces no error.
• Using an action result is always flagged, independent of the body:
  • action returning "literal" with name → flagged
  • action returning read content from f → flagged
  • action returning a value first store out as "" then change out to read content from f → flagged
• Same root cause surfaces at open file at <call-result> (per Enhancement: outbound HTTP client needs POST/headers/auth (and HMAC-SHA256) for real API integrations (e.g. Stripe) #558's note) — anywhere a Text parameter meets an action-call result.

So the trigger is "result of a user-defined action used where Text is required," i.e. the action's declared/inferred return type is Nothing rather than the type of its return expression.

Impact

Non-fatal (labeled error[ERROR] but execution continues), but noisy: any real program that factors request handling / file reading into actions and passes results to respond/open file prints a wall of these on every run. It undermines principle #4 (clear, trustworthy error reporting) — a real type error would be lost in the false positives. Concretely, a dynamic WFL web server (route handlers returning HTML/JSON, static-asset readers, an ACME-challenge reader) prints one per handler.

Expected

Infer an action's return type from its return expression(s) (union when they differ), so a call result carries that type at the call site. At minimum, don't emit a Text-mismatch error when the value's type is unknown/Nothing due to un-inferred action returns.

Discovered while

Adding native HTTPS + Let's Encrypt (ACME HTTP-01) support to a WFL web app — the challenge/asset/route handlers are all actions whose results feed respond to req with ….

[logbie]

Assessment: resolved by #575 — recommend verification + close.

This is the standalone of the return-type-inference family (siblings #560/#557). PR #575 ("fix: infer user-defined action return types in the type checker") merged to main today (2026-07-05 09:03, commit 251b30d3) and its description names this issue directly. It replaces the blanket Nothing default with inference from each action's reachable return expressions (identical types collapse; divergent/un-inferrable types widen to a permissive type) and writes the real type onto the action symbol so call sites carry it — exactly the fix shape recommended on the sibling #560. That removes the "wall of false positives" (Expected Text but found Nothing) in programs that factor request handling / file reading into actions.

Next step: pull main, re-run your isolated repro (call an unannotated action, feed the result to respond to req with … / open file at …), confirm the ERROR is gone, then close. One caveat — #578 still tracks a residual inference gap ("untyped params defeat inference", e.g. double of 5 minus 1); if your repro only regresses on the untyped-parameter variant, that residue lives in #578 and this issue can still close on its primary symptom. Suggested: close as fixed by #575.

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

[logbie]

Verified resolved on current main — recommend closing.

PR #575 ("infer user-defined action return types in the type checker") landed this. An action returning a concatenated string, used at a Text-expecting position (respond to req with c, display c), no longer prints Expected Text but found Nothing — the action's return type is inferred from its return expression, so the call result is typed correctly at the call site.

---

Generated by Claude Code

[logbie]

Verified fixed on WFL 26.7.36 (fc21f2f, Linux release build) during the #610 Phase 1 open-issue inventory.

Fixed by PR #575 — the type checker now infers a user-defined action's return type from its return expressions (after the body is checked), so a call/of result carries its real type at the call site instead of Nothing.

Repro (a call result fed to a Text-requiring builtin position) now runs clean:

define action called h with parameters name:
    store greeting as "hello "
    return greeting with name
end action
store c as call h with "world"
store part as substring of c and 0 and 3
display part

$ wfl repro.wfl
hel
[exit 0]

No more spurious Expected Text but found Nothing. Genuine mismatches (e.g. a Number-returning action used where Text is required) still report correctly. Closing as completed.

---

Generated by Claude Code