diagnostic codes / Traps

E9004 cast-overflow-trap

A float-to-integer cast had no integer in range.

Casting `f64` to an integer truncates toward zero, and a value outside the target type's range traps. `cast<i32>(3.5e9)` has no `i32` to truncate to. Integer-to-integer casts are different: they wrap, and `cast<i8>(200)` is `-56` with no trap.

What it looks like

use tier core;

fn main() -> i32 {
    print_i32(cast<i32>(3.5e9));
    return 0;
}

ralt run e9004.tp
tripon trap E9004 cast-overflow-trap at e9004.tp:4
echo $?
101

`ralt explain E9004` does not know this code yet: it answers with the internal-error row (`name: internal`, `report this to the Tripon repo with a minimal repro`). The code is real, `spec/errors.csv` lists it, and the trap is the one above; only the explain table is missing the row.

What to do

• Check the float against the target range before the cast.
• Cast to a wider integer first if the value may be large: `cast<i64>` before `cast<i32>` truncates the same way, so check the value instead.
• If the cast is a guess at the value's shape, the input needs validating before it reaches this line.

Why the code exists

Converting a float that is out of range is not a rounding question; there is no answer. Trapping keeps it from becoming whatever the hardware happens to produce.

What ralt explain says

ralt explain E9004
E9004
severity: error
name: internal
hint: report this to the Tripon repo with a minimal repro

That is the fallback row, not the trap. The code above is what the driver prints when it does not recognise an argument; the trap path never consults the table, so a program can trap with E9004 while explain still says internal.

Related

• Types and inference /docs/language/types
• Traps and no-UB /docs/language/traps