Typechecker: unannotated action return types default to Nothing, causing false "Cannot index into Nothing" warnings

[logbie]

Summary

Calling a user-defined action that has no explicit return type annotation types the call result as Nothing, even when the action clearly returns a value. Any use of that result — indexing, member access, further inference — then produces false typechecker warnings like Cannot index into Nothing - Expected List of Unknown but found Nothing and cascading Cannot determine type of variable '...'. The program runs correctly; only the static diagnostics are wrong.

Noticed while fixing #559: the fix's doc example and TestPrograms/database_sqlite_test.wfl sections that return a query from an action run fine but emit these warnings.

Environment

• WFL 26.7.4, Linux, current main

Reproduction

Databases not required — any value-returning action shows it:

define action called get_list:
    return [1 and 2]
end action

store xs as call get_list
store x0 as xs[0]
display x0

Output (program still runs and prints 1):

Type checking warnings:
error[ERROR]: Cannot index into Nothing - Expected List of Unknown but found Nothing
  ┌─ rettype.wfl:5:15
  │
5 │ store x0 as xs[0]
  │               ^ Type error occurred here

error[ERROR]: Cannot determine type of variable 'x0'
  ┌─ rettype.wfl:6:9
  │
6 │ display x0
  │         ^ Type error occurred here

Root cause

In src/typechecker/mod.rs, Statement::ActionDefinition handling registers the action's symbol type with:

let return_type_value = return_type.as_ref().cloned().unwrap_or(Type::Nothing);

An unannotated action is recorded as Function { ..., return_type: Nothing }, and Expression::ActionCall inference then propagates Nothing as the call result type. Since WFL actions are commonly written without return type annotations, effectively every value-returning action call is mistyped.

Expected

One of (in order of preference):

1. Infer the return type from the action body's return/give back statements (unify multiple returns; Nothing only when there is no value-returning return statement).
2. At minimum, default the unannotated return type to Unknown instead of Nothing, so downstream inference degrades gracefully rather than producing false errors.

Impact

Cosmetic but noisy: false-positive ERROR-level warnings on the very common "small helper action returns a value" pattern, which can drown out real diagnostics and erode trust in the typechecker. Execution is unaffected.

Related

• Observed while working on Parser: return query/execute ... and parameters [...] fails ("Unexpected token in expression: KeywordParameters") #559 (return query ... and parameters [...]), whose doc example triggers the warning.
• Same neighborhood as previous inference fixes Type checker: store <var> as <builtin> of ... inside an included file fails inference ('Could not infer type') — follow-on to #547 #551 and Type checker: more RHS forms fail inference inside included files — index / object-index / comparison / length of (follow-on to #551) #553.

[logbie]

Assessment: confirmed bug (static-diagnostics only; runtime is correct).

I reproduced your root cause against main: in src/typechecker/mod.rs the Statement::ActionDefinition arm registers the symbol with

let return_type_value = return_type.as_ref().cloned().unwrap_or(Type::Nothing); // ~line 737

so every unannotated action becomes Function { …, return_type: Nothing }, and Expression::ActionCall inference then propagates Nothing into any downstream use — hence the false Cannot index into Nothing and the cascading Cannot determine type of variable. Worth noting the same file already uses Box::new(Type::Unknown) as a return-type sentinel in other arms (around line 2653), so Unknown is an established, safe fallback here.

Fix shape — your ordering is right:

1. Preferred: infer the return type by unifying the body's return/give back expressions; fall back to Nothing only when there is genuinely no value-returning return.
2. Minimum viable: change the line-737 default from Type::Nothing to Type::Unknown so downstream inference degrades gracefully.

Both are backward-compatible (they change diagnostics, not execution, so nothing in TestPrograms/ regresses). This is the sibling of #567 — fixing this one to yield Unknown also feeds cleaner types into the strict rules that #567 is about, so I'd tackle them together. TDD: add a failing typechecker test that defines an unannotated value-returning action, calls it, indexes the result, and asserts no ERROR. Suggested labels: bug, typechecker (already has bug).

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. The repro (define action called get_list: return [1 and 2] … store xs as call get_list … store x0 as xs[0]) now runs with no Cannot index into Nothing or Cannot determine type of variable 'x0' warnings — the call result carries the inferred list type. (The Any/Unknown-from-indexing sibling cases from #567 are handled on branch claude/github-issues-review-i7upri.)

---

Generated by Claude Code

[logbie]

The repro here type-checks clean on current main (34512e8) — store xs as call get_list; store x0 as xs[0] now prints 1 with no diagnostic, thanks to the post-body return-type inference from #575. Looks closeable from my side.

One recursive residual with the same root cause (the provisional Nothing seed) survives, since the body is checked before inference completes and a self-recursive call can't see its own inferred type — filed separately as #590 with a minimal repro and a suggested Unknown-seed fix.

---

Generated by Claude Code

[logbie]

Hit this again while working on Scriptorium, so I hunted down the shapes that survived #575/#591. Two residuals found and fixed on branch claude/issue-560-fix-lu08sd (commit 257f2e1):

1. return inside a try: block was invisible to inference — collect_return_types never descended into TryStatement, so an action whose only returns live inside a try body / when error / otherwise / finally was inferred as returning Nothing, reproducing the exact false Cannot index into Nothing from this issue. Try blocks wrap precisely the file/DB/parse work helper actions return values from, which is why real programs keep tripping it. WaitForStatement had the same gap.

2. Container methods were still registered as returning Nothing — the analyzer's container registry used unwrap_or(Type::Nothing) for unannotated methods and nothing ever refined it, so instance.method() results hit the same false error (the container-flavored twin of the original report, which fix: infer user-defined action return types in the type checker #575 only fixed for top-level actions). Methods are now seeded Unknown and the type checker infers the real return type from each method body and writes it back to the registry; inherited method calls are fixed by the same registry update.

TDD: tests/action_return_type_residuals_test.rs (4 tests, confirmed failing first). Full suite, clippy -D warnings, and all 106 TestPrograms/ pass; a combined Scriptorium-shaped stress case (recursive action indexing a map returned from inside try, wrapped by a container method) type-checks completely clean.

---

Generated by Claude Code