Numeric conversion spec by ESRogs · Pull Request #25 · ESRogs/roc

ESRogs · 2026-08-12T19:25:20Z

Rebuild of roc-lang#10736 against conversion-spec-design.md, split into small commits. Iteration happens here; roc-lang#10736 gets reset to this once it settles.

The spec is the triple (src, dst, mode) parsed from each op name once, at comptime. There is no shared grouping enum: consumers route on the source and destination classes, then switch on the mode, splitting further where a handler assumes more than the spec says.

Five comptime rules run over the whole enum, so any build of the compiler checks them:

an op named like a conversion either classifies or is listed as not one.
rebuilding a name from its triple reproduces the original.
every conversion occupies one of the sixteen class-and-mode combinations.
every combination is occupied by some conversion.
a string conversion's number type and direction rebuild its name.

Each rule was verified by breaking it and confirming the build fails naming the op.

All four consumers derive from the spec. The LLVM backend routes on it; dev, wasm, and the interpreter keep the op prongs ci/zig_lints.zig requires and drop the facts they restated. Three of those commits exist because a table did not merely repeat an op name but misnamed a field.

The last three commits extend the spec to a number's text and are removable as a unit.

Verification of the LLVM dispatch swap. No CLI flag emits LLVM IR, so test/fx/runtime_dec_to_int_wrap_widths.roc was compiled at --opt=speed on the commit before and after: byte-identical binaries, same SHA-256. That fixture drives all ten Dec-to-integer widths plus truncation and past-I64 wrapping.

Suites at f07d9db39b, compared against roc-lang/roc main 7f9b644e33. run-check-* passes. Eval on the interpreter, dev, and wasm executors is 1930/1930. Under --llvm 23 tests fail, and under run-test-cli 9 fail; both sets carry the same names on the baseline, so neither belongs to this branch. The --llvm baseline additionally hangs 10 tests that pass here, at a count that varies between runs on this machine, so that difference is not attributable either way.

ESRogs · 2026-08-14T21:10:17Z

+
+/// Ops whose names contain `_to_` but do not convert between two number types.
+/// Listing one here is how it is excused from
+/// `assertNothingConversionShapedEscapes`.


Why don't we put it next to that assert then?

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The integer-to-Dec branch reads the source's signedness, which is what the replaced table's target-signedness field held for those two ops. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The range bounds are computed where they are emitted, which is only for destinations narrower than 64 bits; the replaced table stored unread placeholders for the two 64-bit entries. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The 214 arms named a helper and its type arguments per op. A router picks both from the spec instead, so the switch keeps only the op names the lint requires. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Thirteen `*_to_str` ops leave the not-a-conversion list, so rule 0 now accounts for them by what they are rather than by exclusion. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`numericParseSpec` moves beside the parse it now reads, since `LowLevel` imports nothing and importing the spec there would close a cycle. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ESRogs · 2026-08-19T22:15:31Z

+}
+
+/// Split a name such as `dec_to_u64_trunc` into its three parts. Returns null
+/// unless both ends are a `NumType`, which is what separates a conversion from


Two options

/// Split a name into `source`, `"_to_"`, and `destination`. If either `source` or `destination` is not a `NumType`, it returns null.

or:

/// Match a name against `"${source}_to_${destination}`. If either `source` or `destination` is not a `NumType`, it returns null.

Though not sure if that's the right way to describe the template in zig. Not sure if fixable, or we should just go with the first option.

Oh, maybe we should use src and dst rather than source and destination.

Also, is "name" too generic? Like what kind of name is it? I think that's why I was suggesting the example. Also "parse" is pretty generic too.

ESRogs · 2026-08-19T22:18:32Z

+/// Split a name such as `dec_to_str` into a number type and a direction.
+/// Returns null unless the half beside `str` is a `NumType`, which is what
+/// separates `dec_to_str` from `num_to_str`.
+fn parseString(name: []const u8) ?StringConversion {


parseString does not at all sound like it means "parse the name of a function that converts a numtype to a string."

ESRogs force-pushed the conversion-spec branch 7 times, most recently from 3c49461 to f07d9db Compare August 13, 2026 21:00