Typechecker: Any/Unknown values from list indexing and untyped parameters rejected by strict ERROR rules (false positives)

[logbie]

Summary

Values whose static type is Any (list-index results) or Unknown (untyped action parameters) are rejected by several ERROR-level typechecker rules instead of degrading gracefully. The program runs correctly in every case; only the static diagnostics are wrong.

This is the sibling of #560: that issue covers action-call results being mistyped as Nothing; this one covers Any/Unknown values flowing into operator/statement checks. Together they account for all the false warnings emitted by the rewritten Tools/rust_loc_counter.wfl (a warning-per-shape inventory is at the bottom).

Environment

• WFL 26.7.6, Linux, release build, current main

Reproduction 1 — list index result (Any) rejected by add ... to

store rows as [[10 and 20]]
store total as 0
for each r in rows:
    store t as r[1]
    add t to total
end for
display total

Output (program still runs and prints 20):

Type checking warnings:
error[ERROR]: Cannot add non-numeric value to number - Expected Number but found Any
  ┌─ repro_any.wfl:5:5
  │
5 │     add t to total
  │     ^ Type error occurred here

The same Any-from-indexing value also trips the subtraction rule (Cannot perform Minus operation on Number and Any) when used as n minus t.

Reproduction 2 — untyped parameter (Unknown) rejected by split ... by

define action called split_words with p:
    store parts as split p by " "
    return parts
end action

store ws as call split_words with "a b"
display "done"

Output (runs fine, prints done):

Type checking warnings:
error[ERROR]: Expected Text for string splitting, got Unknown - Expected Text but found Unknown
  ┌─ repro_unknown.wfl:2:20
  │
2 │     store parts as split p by " "
  │                    ^ Type error occurred here

Note the inconsistency: arithmetic on the same kind of Unknown parameter (length of p then n minus 1) produces no warning, so some rules already treat Unknown as compatible while others reject it.

Expected

Gradual-typing semantics: Any and Unknown should be accepted by these checks (they represent "statically unknown", not "known to be wrong"). Warnings at ERROR level should be reserved for types that are provably incompatible. Concretely:

• add X to <number> / binary arithmetic: accept Any/Unknown operands
• split X by Y: accept Any/Unknown for the text operand
• indexing an Unknown/Any parameter should not cascade into Could not infer type for variable '...' for every downstream variable

Impact

Cosmetic but very noisy: a ~450-line script that leans on untyped action parameters and list rows (e.g. Tools/rust_loc_counter.wfl) emits ~26 ERROR-level warnings on a fully correct program. That drowns out real diagnostics and erodes trust in the typechecker.

Warning inventory from one run of wfl Tools/rust_loc_counter.wfl (all false positives; the tool's output is verified byte-identical to its Python reference):

 8x  Cannot add non-numeric value to number - Expected Number but found Any
 4x  Cannot index into Nothing - Expected List of Unknown but found Nothing   (covered by #560)
 2x  Expected Text for string splitting, got Unknown
 1x  Cannot perform Minus operation on Number and Any
 1x  File content must be a text string - Expected Text but found Nothing     (covered by #560)
 1x  Collection in for-each loop must be a list or map - found Nothing        (covered by #560)
11x  Could not infer type for variable '...' (cascades from indexing an untyped parameter)

Related

• Typechecker: unannotated action return types default to Nothing, causing false "Cannot index into Nothing" warnings #560 — unannotated action return types default to Nothing (the other root cause in the inventory above)
• Type checker: more RHS forms fail inference inside included files — index / object-index / comparison / length of (follow-on to #551) #553 — the include-path variant of inference gaps (fixed); this issue is about the main-file path

[logbie]

Assessment: confirmed bug — sibling of #560.

Verified against main: the strict ERROR sites you hit are real — Cannot add non-numeric value to number at src/typechecker/mod.rs:1533 and Expected Text for string splitting at ~line 2925 (with the parallel pattern/replace/delimiter checks at 2797/2826/2858/2894/2935). They reject Any (list-index result) and Unknown (untyped parameter) as if provably-wrong, when those types mean "statically unknown." Your observed inconsistency is real too: the arithmetic path already tolerates Unknown for length of p / n minus 1, so the tolerance is applied unevenly.

Fix shape: treat Any and Unknown as gradually-typed in these checks — accept them and reserve ERROR-level diagnostics for types that are provably incompatible. Cleanest is a small helper (e.g. is_gradual(ty) -> matches Any | Unknown) applied uniformly across the arithmetic and text-operation rules so no rule is missed. Backward-compatible (diagnostics only). Best fixed alongside #560: if unannotated action returns become Unknown instead of Nothing there, and these rules accept Unknown here, the whole class of false positives on the "small helper returns a value" pattern goes away. TDD: failing tests for both repros (add Any to a number; split an Unknown parameter) asserting no ERROR. Suggested labels: bug, typechecker.

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

[logbie]

Fixed on branch claude/github-issues-review-i7upri.

The type checker now treats Any/Unknown as "statically unknown" rather than "known incompatible" (gradual typing):

• add X to <number> and add X to <list> accept Any/Unknown operands.
• Binary arithmetic on an Any operand degrades gracefully (mirrors the existing Unknown handling) instead of raising Cannot perform … operation; comparisons still yield Boolean, and Plus with a Text operand still yields Text.
• split X by Y accepts Any/Unknown for both operands.
• Referencing a binding with no recorded type (most commonly an untyped parameter) now yields Unknown silently instead of Cannot determine type of variable, which also cuts the cascade.

Repros 1 and 2 now run clean with no Type checking warnings. Regression tests added. (The sibling return-type issues #560/#569 were already resolved by #575.)

---

Generated by Claude Code

[logbie]

Status: verified merged on main — recommend closing.

The prior comment left this at "fixed on branch claude/github-issues-review-i7upri". That branch merged: PR #587, commit 2c52826.

Evidence on current main:

• src/typechecker/mod.rs was reworked (+59/-40 in that commit) to treat Any/Unknown as statically unknown rather than as a concrete type to reject — which is the gradual-typing behavior this issue asked for. That removes the false-positive ERRORs on list-index results and untyped parameters.
• Regression tests in tests/github_issues_batch_test.rs cover each symptom you reported: any_from_list_index_accepted_by_add, any_from_list_index_accepted_by_arithmetic, concrete_value_accepted_into_list_of_any (the "Cannot add Text to list of Any" case), unknown_param_accepted_by_split, plus store_unknown_call_result_binds_silently / ..._chained_binds_silently for the Type checker: store x as <action call> raises ERROR "Could not infer type for variable" whenever the callee's return type is Unknown #588 overlap.
• All green in the Integration Tests job on main.

If you're still seeing a strict-rule false positive that isn't in that list, it'd be worth a fresh issue with the repro rather than reopening this one — the sibling family (#560, #569, #588) has since been closed out too.

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

[logbie]

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

Fixed by PR #587 — add … to, binary arithmetic, and split … by now accept Any/Unknown operands and degrade gracefully under gradual typing.

Repro 1 (list-index Any into add ... to) now runs with no diagnostics:

$ wfl repro_any.wfl
20
[exit 0]

No more error[ERROR]: Cannot add non-numeric value to number - Expected Number but found Any. (The sibling VariableDeclaration-path case was tracked separately as #588 and is likewise fixed.) Closing as completed.

---

Generated by Claude Code