sx/issues/0095-typed-local-float-int-narrowing.md

0095 — typed local/decl silently truncates a float initializer to an integer annotation

RESOLVED (F0.11). Agra ruled the UNIFIED rule (Option B): an implicit float→int in a typed binding behaves exactly like the array-dimension rule — an integral float FOLDS to its integer (4.0 → 4, -2.0 → -2), a non-integral float is a COMPILE ERROR (1.5, 4.5), and an explicit xx / cast(T) ALWAYS truncates (the escape). Applied consistently across typed local / param-default / field-default, typed module CONST, and array dim — all reusing the single program_index.floatToIntExact / evalConstIntExpr facility (no second integral check).

Fix (src/ir/lower.zig, src/ir/module.zig, src/ir/program_index.zig):

• Builder.constFloatInfo reads a compile-time const_float back from its Ref (value + span).
• coerceToType now means IMPLICIT coercion: its .float_to_int arm folds an integral const-float to constInt, else emits the narrowing diagnostic. coerceExplicit is the raw truncating path; xx (lowerXX) and cast(T) route through it so the escape still truncates.
• Field-default lowering (struct-literal pad, named-field default, buildDefaultValue) now coerces the default to the field type at the IR level (was silently bit-coerced by emitStructInit).
• Const path: typedConstInitFits accepts an integral float (literal or a M + 2.0-style expression that folds via evalComptimeInt); emitModuleConst / constExprValue / globalInitValue fold an integral float to its int and reject a non-integral one.

Completion (F0.11 attempt 2) — the direct-const_float coerce arm only caught a float LITERAL; a non-integral const-folded float EXPRESSION (local/field/param : s64 = M + 0.5) still truncated silently. Closed by:

• New program_index.evalConstFloatExpr — the f64 counterpart to evalConstIntExpr, delegating every integer subtree back to it (no parallel integer logic), adding only the float literal / negate / + - * / arms.
• Lowering.foldComptimeFloatInit routes the typed LOCAL, struct FIELD default, and call ARGUMENT (incl. an expanded param default) through evalConstFloatExpr + floatToIntExact: an integral comptime float folds, a non-integral one errors, a genuine runtime float / xx cast is left to the normal path. (Run pure evalConstFloatExpr FIRST so a $pack[i] arg isn't spuriously type-resolved out of binding.)
• One Lowering.diagNonIntegralNarrow now emits the narrowing wording at all five sites (coerce arm, global init, const-expr value, the typed-binding sites, and the typed-const path), so the typed-CONST non-integral diagnostic reads cannot implicitly narrow non-integral float … instead of the stale initializer is a float literal / floating-point expression.

Completion (F0.11 attempt 3) — attempt 2 resolved INT-const-expr leaves (M + 0.5, M :: 2), but a non-integral result via a FLOAT-const leaf (F : f64 : 2.5; y : s64 = F + 0.25 = 2.75) still truncated silently: evalConstFloatExpr delegated only integer leaves to evalConstIntExpr and had no float-const leaf arm. Closed by completing the evaluator:

• program_index.moduleConstFloat — the f64 twin of moduleConstInt (same isCountableConstType gate, same cyclic-definition frame), recovering a numeric module const's value through evalConstFloatExpr. A new lookupFloatName ctx method (on Lowering and ModuleConstCtx) surfaces a NON-INTEGRAL float const leaf; evalConstFloatExpr gained .identifier / .type_expr arms that call it. Integer / integral-float leaves keep resolving through the existing evalConstIntExpr delegation, so the unified rule now applies to ANY compile-time-constant float expression — literal, int-const leaf, float-const leaf, and combinations — at every binding site.
• typedConstInitFits now judges integral-fold via evalConstFloatExpr + floatToIntExact (the SAME facility foldComptimeFloatInit uses) instead of the int-only evalComptimeInt, which folded leaf-by-leaf in i64 and so rejected an integral SUM built from a non-integral float leaf (K : s64 : F + 1.5 = 4.0). Integral float-const-leaf consts now FOLD; non-integral ones still error with the unified wording.
• Out of scope (consistent with the int evaluator): a LOCAL :: const leaf is resolved as a scope ref, not through the const tables, so neither evalConstIntExpr nor evalConstFloatExpr folds it — a local M : s64 : 2 in M + 0.5 and a local F : f64 : 2.5 in F + 0.25 both still truncate identically. Float now matches int exactly at that boundary.

Completion (F0.11 attempt 4) — attempts 1–3 unified the four binding sites (local / field / param / const) for compile-time float exprs, but the ARRAY- DIMENSION / count path still diverged: it folded a DIRECT integral float literal ([4.0], [N] with N : f64 : 4.0) yet rejected an INTEGRAL expression built from a non-integral float-const leaf ([F + 1.5] = 4.0, or [K] with K : s64 : F + 1.5) as "must be a compile-time integer constant" — because the dim fold used the int-only evalConstIntExpr, never the float-aware path. Closed by routing the count fold through the SAME facility the other four sites use:

• New program_index.foldCountI64 — the single int-or-integral-float count fold: evalConstIntExpr first, then (only on failure) evalConstFloatExpr + floatToIntExact. foldDimU32 (array dim / Vector lane / u32 value-param) and the non-u32 value-param gate both delegate to it, so no count site disagrees on which floats fold (the issue-0083 unify-or-diverge rule extended to floats).
• A new DimU32.non_integral_float variant carries a non-integral float dim to a distinct, accurate diagnostic ("array dimension must be an integer, but '2.75' is a non-integral float") rather than the generic "must be a compile-time integer constant" — the cast-escape advice the binding sites give does not apply in a dimension position, so the dim wording omits it. reportDimError, the Vector-lane resolver, and the top-level array-alias diagnostic all handle the new variant, so the DIRECT (a : [F + 0.25]s64) and type-ALIAS (Arr :: [F + 0.25]s64) forms emit the identical message.
• type_bridge.StatelessInner.lookupFloatName (routed through moduleConstFloat) is the float twin of its lookupDimName, so the registration-time alias path folds a float-const-leaf dimension to the SAME count as the stateful direct path. This relaxes the F0.4 examples/1132 wording (a non-integral float const dim now reports the precise "non-integral float" message; it still errors).

Regression tests: examples/0168-types-integral-float-to-int.sx (positive — local/field/param/const fold, integral int-const-EXPRESSION (M + 2.0) AND float-const-LEAF (F + 1.5, F : f64 : 2.5) fold at local/field/param/const, xx/cast truncate incl. xx (M + 0.5) / xx (F + 0.25)), examples/1146-diagnostics-nonintegral-float-to-int.sx (negative — non-integral LITERAL, int-const-EXPRESSION (M + 0.5), AND float-const-LEAF (F + 0.25) error at local/param/field), the integral-float const cases in examples/0162-types-typed-module-const-roundtrip.sx, and the aligned const diagnostic in examples/1143-diagnostics-typed-module-const-mismatch.sx (G / BAD / BAD2 stay errors with the new wording). The array-dimension site is pinned in the same two examples: 0168 adds [F + 1.5]s64, [KF]s64 (KF : s64 : F + 1.5), and a type-alias ArrFE :: [F + 1.5]s64 all folding to len 4; 1146 adds [F + 0.25]s64 erroring; examples/1132 now expects the precise non-integral-float dim wording. Unit: program_index.test.zig "evalConstFloatExpr folds comptime float expressions" (covers the float-const leaf: F → 2.5, F + 0.25 → 2.75, F + 1.5 → 4.0) and "foldCountI64 / foldDimU32 fold an integral float count, reject a non-integral one" (the count fold + the non_integral_float / below_min distinction).

Symptom

A typed LOCAL (and likely typed param/field) silently truncates a floating-point initializer to an integer annotation instead of rejecting or requiring an explicit cast.

Observed:

• y : s64 = 1.5; → y == 1 (float literal truncated, no diagnostic)
• y : s64 = 2 + 0.5; → y == 2 (float-valued expr truncated, no diagnostic)

Expected: a type-mismatch / narrowing diagnostic (consistent with typed MODULE CONSTS, which after F0.7 reject N : s64 : 1.5 and N : s64 : M + 0.5). Today consts are strict but locals are lenient — an inconsistency.

Reproduction

#import "modules/std.sx";
main :: () {
    y : s64 = 1.5;
    print("{}\n", y);   // prints 1
}

Investigation prompt

Decide + implement the language rule for implicit float→int narrowing in a TYPED binding (local / param / field) initializer. Module consts already reject it (F0.7, registerTypedModuleConst + typedConstInitFits/constExprInitFits). Make typed-local/param/field assignment-coercion consistent: either reject a non-integral float→int initializer with a diagnostic (matching the const path) or require an explicit xx/cast. Suspected area: the assignment / typed-binding coercion path (coerceToType ladder, specs.md §"coercion") in src/ir/lower.zig. Verify y : s64 = 1.5 errors (or requires a cast); confirm integral-float folding rules (specs.md: 4.0→4 ok, 4.5 rejected) stay consistent. Then gate.

Disposition

Discovered during F0.7 (issue 0088) attempt-2 review. Agra ruled F0.7 fixes the inferExprType ROOT for binary-op promotion; this typed-LOCAL narrowing is a SEPARATE assignment-coercion concern -> its own scheduled step.