Pull Request Overview

This PR implements the "let?" syntax (LetUnwrap) as an experimental feature for ReScript, providing syntactic sugar for early-return patterns with Result and Option types. The implementation hides this functionality behind an experimental feature flag that must be explicitly enabled.

Key changes:

• Adds thelet? syntax that automatically unwraps Result/Option types with early return behavior
• Implements experimental feature infrastructure with configuration support in rescript.json
• Provides comprehensive error handling and validation for the new syntax

Reviewed Changes

Copilot reviewed 40 out of 40 changed files in this pull request and generated 3 comments.

_{Tip: Customize your code reviews with copilot-instructions.md.Create the file orlearn how to get started.}

I tried this out in a bsb project with"bsc-flags": ["-enable-experimental", "LetUnwrap"] and it all works perfectly 🎉

Great work@zth 😁

Auto gen quick summary + detailed risk analysis:

What’s new (user-facing, with a dev sketch)

Feature:let? (“let-unwrap”) — a tiny syntax that unwrapsresult/option values andearly-returns onError/None. It’s explicitlyexperimental anddisabled by default behind a new “experimental features” gate. ([GitHub]1, [ReScript Forum]2)

How you’d use it

letgetUser=async (id)=> {let?Ok(user)=awaitfetchUser(id)let?Ok(decodedUser)=decodeUser(user)Console.log(`Got user ${decodedUser.name}!`)let?Ok()=awaitensureUserActive(decodedUser)Ok(decodedUser)}

This desugars to a sequence ofswitch/early-returns that you’d otherwise write by hand, so there’sno extra runtime cost and it plays nicely withasync/await. Same idea works foroption withSome(...) (and the PR also extends support so the left pattern can beError(...)/None, not justOk(...)/Some(...)). ([ReScript Forum]2, [GitHub]3)

Where it works (and doesn’t)

• Targetsbuilt-ins only:result andoption. (Custom variants still needswitch.) ([ReScript Forum]2)
• Block/local bindings only; tests show top-level usage is rejected. ([GitHub]3)
• The printed JS is the straightforward if/return form (i.e., “zero cost”). ([ReScript Forum]2)

How to enable it (experimental)

• The PR adds anexperimental-features infrastructure to the toolchain andCLI support:-enable-experimental …. Rewatch reads config fromrescript.json and forwards the feature(s) to the compiler. (Seerewatch config + compile changes and the new compiler flag.) ([GitHub]3)
• There are tests and docs stubs around the experimental toggle plus “feature not enabled” error cases. ([GitHub]3)

In short: add the feature inrescript.json via the new “experimental features” setting (per the updatedCompilerConfigurationSpec.md), or pass-enable-experimental in your build; otherwiselet? is unavailable. ([GitHub]3)

Dev notes (what changed under the hood)

• Lexer/Parser/Printer: new token forlet?, grammar rules, and pretty-printer support. ([GitHub]3)
• Frontend transform: AST handling lowerslet? to the equivalentswitch/early return; tailored super-errors for misuse. ([GitHub]3)
• Feature gate: new module(s) to register/enable experimental features, with CLI wiring and rewatch config reading. ([GitHub]3)
• Tests: syntax parsing, printer snapshots, super-errors (e.g., “feature not enabled”, “top-level not allowed”, “not supported variant”, and return-type mismatch). ([GitHub]3)

Safety analysis: can this break anything whenoff?

Bottom line: extremely low risk when the flag isoff.

Why:

1. Gated by default. The feature is unreachable unless explicitly enabled; usinglet? without the gate yields a dedicated “feature not enabled” error (there are fixtures for this). That means existing codebases remain unaffected. ([GitHub]3)
2. New syntax, not repurposed.let? didn’t previously parse; recognizing it only at alet binding start avoids collisions with existing? uses (e.g., ternary) elsewhere in expressions. Parser tests were added to lock this down. ([GitHub]3)
3. No runtime path changes. It’s a compile-time sugar that lowers to the sameswitch/return structure you’d hand-write. If you don’t use it, nothing in your generated JS changes. ([ReScript Forum]2)
4. Confined scope. Even when enabled, top-levellet? is rejected; only local/block bindings are supported. This reduces any accidental global impact. ([GitHub]3)
5. Tooling guarded. The PR tracks TODOs for error coverage and editor support; with the gate off, current editor plugins behave as before. ([GitHub]1)

Potential edge considerations (still low risk off):

• Tokenization side-effects: The scanner learns thelet? token, but the feature gate + grammar location prevents it from altering how existing, valid programs lex/parse when you don’t writelet?. Tests cover “not enabled” and misuse shapes. ([GitHub]3)
• Error text churn: Some super-error messages were added (including a hint when code lookseligible forlet?). That only triggers in error paths; it won’t change successful builds. ([GitHub]3)

Conclusion: With the experimental flagoff, there are no functional or runtime changes, and parser behavior for all previously valid code paths is preserved. It’s safe to ship behind the flag.

If you want, I can also jot down a tiny rollout checklist (enable flag in a sample app, verify editor plugin snapshot, run the super-errors suite) next.