char is now an alias of int, so char literals and ints mix freely, including in switch patterns.
Int range patterns such as 200 .. 299 are supported in switch, and their bounds may mix ints and chars.
๐ Polish
Char range patterns such as '\u{0}' .. '\u{10FFFF}' compile as fast as a single character, and missing-case warnings show ranges instead of listing every character.
char was a private abbreviation of int: a char could be coerced to an int with :>, but an int could not be used as a char. It is now a plain alias, so char literals and ints mix freely, including in one switch. Pattern matching treats a char constant and an int constant with the same value as the same constant, for exhaustiveness, unused cases and switch compilation. Char literals keep their spelling in generated JavaScript comments and in warning examples. First step of #7028.
Example ReScript
let f = x =>switch x {| '\000' .. '\255' =>0| 'ล' =>2| _ =>3 }
Source tests/tests/src/string_unicode_test.mjs in the diff (the range starts at code point 0, written as a literal NUL character in the test).
๐ New featurechar is now an alias of int, so char literals and ints mix freely, including in switch patterns.
Review
Why keep Const_char instead of typing char literals as ints? It keeps the /* 'a' */97 comments in the JavaScript and the char spelling in warnings such as "for example: | '\x00'".
Why do char switches now use int32 bounds instead of 0..max_int? A char can now hold any int, including negative ones, so a switch can no longer assume x >= 0. Two committed snapshots change for that reason.
Do integer range patterns such as 1 .. 5 work now? No, they still report Invalid_interval. Char ranges expand to one case per value, which does not scale to arbitrary ints; that needs interval patterns of their own.
No effect
Formatting: unchangedFormats: nonePPX: unchanged
Output
changedtests/tests/src/adt_optimize_test.mjs and string_unicode_test.mjs, char switches whose range starts at '\000' now send negative values to the default case
Editor
pipecompletion on a char value offers Int functions; it offered none before (tests/analysis_tests/tests/src/CompletionChar.res)
Errors
ERROR_VARIANTS.md warnings section lists the two new warning 8 and 11 fixtures
Represent char range patterns with a typed-tree node
๐ Polishtypecheckerlambdaanalysistests
A char range pattern such as 'a' .. 'z' used to be expanded by the type checker into an or-pattern with one constant per character, so compile time and memory grew with the width of the range. It is now one Tpat_interval node. Exhaustiveness and match compilation split each column at the bounds of its ranges into pieces that every range covers fully or not at all, so the work depends on the number of patterns, not on the number of characters. Missing-case warnings show ranges instead of listing every character.
Example ReScript
let f = (a, b) =>switch (a, b) {| ('a' .. 'z', 'a' .. 'z') =>1| (_, '\u{0}' .. '`') =>2 }
Beforeoutput
You forgot to handle a possible case here, for example: | ('t', '{')| ('u', '{')| ('v', '{')| ('w', '{')| ('x', '{')| ('y', '{')| ('z', '{')
Afteroutput
You forgot to handle a possible case here, for example: | ('a' .. 'z', '{') | ('\x00', 'a')
Source tests/build_tests/super_errors/fixtures/warning_8_char_range_example.res, compiled with the parent commit and with this one.
๐ PolishChar range patterns such as '\u{0}' .. '\u{10FFFF}' compile as fast as a single character, and missing-case warnings show ranges instead of listing every character.
Review
Is the generated JavaScript the same? Every committed snapshot is byte-identical. A differential fuzzer (900 random switches over overlapping char ranges, or-patterns, guards, tuples and options) compiled each program with the parent commit and with this one: results equal a reference evaluation for every input, warning numbers and locations are equal, and the JS differs in shape for some programs and is 0.4% smaller in total (296,645 โ 295,495 characters).
Why are intervals precompiled like or-patterns? An expanded range used to be an or-pattern, whose row is compiled once in a handler. Doing the same for an interval whose row tests further columns keeps that sharing; dividing such rows by piece instead made the fuzzer's output 16% larger.
Why is the action of a range stored as shared? The switch emits it for each value of the range. An expanded range shared it the same way, because its values had equal actions; a copy per value would declare the action's variables twice in one JavaScript scope.
Are int ranges such as 1 .. 5 accepted? Not yet; they still report Invalid_interval. The node and the algorithms already work on int and char constants, for a follow-up.
No effect
Formatting: unchanged
Output
unchangedall committed generated JS is byte-identical (char_range_test.mjs changes with its source)
Formats
cmt(Caml1999T045 -> Caml1999T046)
PPX
unchangedPpat_interval already exists in the v0 parsetree
Editor
unchanged;analysis visits the new node like a constant
Errors
ERROR_VARIANTS.md warnings section lists the two new fixtures
switch now accepts int ranges such as 200 .. 299, and bounds that mix ints and chars, since char is an alias of int. They use the Tpat_interval node char ranges compile to, so a range costs the same however wide it is. Ranges of other constants, such as 1.0 .. 5.0, still report Invalid_interval, whose message now names int and char intervals. Int switches are never exhaustive, as before: a missing-case example is the least uncovered value from 0 up, else the greatest one below 0.
Example ReScript
let status = code =>switch code {|200 .. 299=>"success"|301|302|307|308=>"redirect"|400 .. 499=>"client error"|500 .. 599=>"server error"| _ =>"unknown" }
Source tests/tests/src/int_range_test.mjs in the diff. Before this commit the example reported "Only character intervals are supported in patterns."
๐ New featureInt range patterns such as 200 .. 299 are supported in switch, and their bounds may mix ints and chars.
Review
Does a switch covering all ints count as exhaustive? No. Ints are never matched exhaustively, so warning 8 still reports _ for a switch on -0x80000000 .. -1 | 0 .. 0x7FFFFFFF, as it does for constants.
How was it checked? A fuzzer generated 600 switches over int, char and mixed ranges with negative bounds, or-patterns, guards, tuples and options; the results equal a reference evaluation for every input. Three programs hit Fatal error: Matching.comp_exit; each reduces to | _ => ... | p1 | p2 if g() => ..., which crashes the parent commits the same way with char patterns.
Write missing-case examples beyond char literals as ints
typecheckertests
A missing-case example in a char column took the kind of the first pattern, so a value that no char literal can denote was printed as an invalid one: a switch covering every char literal suggested '\u{110000}'. Such values are now printed as ints.
Example ReScript
let f = c =>switch c {| '\u{0}' .. '\u{10FFFF}' =>1 }
Beforeoutput
You forgot to handle a possible case here, for example: | '\u{110000}'
Afteroutput
You forgot to handle a possible case here, for example: | 1114112
Source tests/build_tests/super_errors/fixtures/warning_8_char_range_beyond.res, compiled with the parent commit and with this one.
Review
Codex found this for mixed ranges on #8894, where an example below 0 was printed as a char; the cause is here.
Primitive_string_extern.getChar returned option<char>; it returns option<int> now that char is an alias of int, which leaves no use of char in the runtime. The generated JavaScript is unchanged.
No effect
Output: unchanged
Tests
nonebecause the type is an alias of the old one and the output is unchanged