Repository navigation
Compare variant literals by their JavaScript value - #8965
Conversation
Why:
The duplicate-literal check compared `@as` literals by spelling, so it
accepted `@as(1) A | @as(1.0) B`, two cases with the same runtime value
that a dispatched `B` matches as `A` (#8953), and rejected
`@as(1) A | @as(1n) B`, two different values.
Literals other than strings are now keyed by the value a `switch` compares
with `===`: an int as the 32-bit number it is emitted as, a float as the
number it parses to, with `-0.` and `0` equal, and a bigint by its
normalized digits, apart from numbers. Constant folding uses the same key,
so a constant bigint case now folds too. The spec's rule 6 states the
comparison, and the known bug is gone.
Diagnostic added (same value, different spelling):
Example:
@unboxed type t = | @as(1) A | @as(1.0) B
After (diagnostic):
This untagged variant definition is invalid: The literal 1.0 is the same JavaScript value as 1.
Diagnostic removed (a number and a bigint):
Example:
@unboxed type t = | @as(1) One | @as(1n) OneN | S(string)
Before (diagnostic):
This untagged variant definition is invalid: Duplicate literal 1.
Breaking: a variant with two `@as` literals that are the same JavaScript
value, such as `@as(1)` and `@as(4294967297)`, is now an error. Such a
variant already matched the second case as the first at run time.
Fixes: #8953
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fc7LEuyEfynjaKCVEBPmTF
Signed-off-by: Christoph Knittel <ck@cca.io>
Semantic Diff1 commit · Full page Compare variant literals by their JavaScript value69f57c0 · Christoph Knittel with Claude Opus 5.5 · Oct 22, 2026
Literals other than strings are now keyed by the value a Diagnostic added (same value, different spelling) @unboxed type t = | @as(1) A | @as(1.0) B
Diagnostic removed (a number and a bigint) @unboxed type t = | @as(1) One | @as(1n) OneN | S(string)
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #8965 +/- ##
=======================================
Coverage 81.22% 81.22%
=======================================
Files 457 457
Lines 63853 63862 +9
=======================================
+ Hits 51865 51875 +10
+ Misses 11988 11987 -1
🚀 New features to boost your workflow:
|
rescript
@rescript/belt
@rescript/darwin-arm64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/runtime
@rescript/win32-x64
commit: |
|
Developer playground preview: https://rescript-lang.github.io/rescript/dev-playground/?version=pr-8965 |
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
cristianoc
left a comment
cristianoc
left a comment
There was a problem hiding this comment.
Great.
I would not call it a breaking change: it follows what has always been the intended spec.
Fixes #8953.
The duplicate-literal check of variants compared
@asliterals by how they are spelled, not by the JavaScript value they become. That fails both ways:@as(1) A | @as(1.0) B1,1BmatchesA@as(1) A | @as(4294967297) B1,1(ints are emitted as 32-bit)@as(0) A | @as(-0.) B===@as(1n) A | @as(001n) B1n,1n@as(1) One | @as(1n) OneN | S(string)1,1n(different)Literals are now keyed by the value a
switchcompares with===: ints as the 32-bit number they are emitted as, floats as the number they parse to, bigints by their normalized digits, apart from numbers. When two spellings meet, the error names both:The key lives in
Variant_runtime.literal_value_key, and constant folding (Lambda.literal_denotes_same) now uses it too. It already compared numbers by value, but treated two equal bigints as different, so a constant bigint case was never folded.UntaggedVariants.mdrule 6 now states the comparison, and the known bug is removed.Breaking: a variant with two
@asliterals that are one JavaScript value is now an error. Such a variant already matched the second case as the first at run time.New tests:
untagged_literal_same_number,untagged_literal_same_int32,untagged_literal_same_bigint.unboxed_variant_fold_test.res: a number and a bigint literal with the same digits, dispatched and folded.🤖 Generated with Claude Code
https://claude.ai/code/session_01Fc7LEuyEfynjaKCVEBPmTF