rescript-lang / rescript-lang/rescript

Proposal: Optional "return" as Syntactic Sugar in ReScript 13

Open
#8,191 7 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
OCaml
Stars
7.5k
Forks
485
Avg merge
1d 2h
Merged PRs (30d)
55

Description

Author: Jonathan Jewell Status: Draft / RFC Goal: Facilitate onboarding for JS/TS developers without compromising ReScript’s functional core.


Overview

Add return as optional syntactic sugar for function expressions. This desugars to the last expression during compilation, with zero semantic or performance impact.

Current ReScript | Proposed (Sugar) | Desugared Output -- | -- | -- let add = (a, b) => a + b | let add = (a, b) => return a + b | let add = (a, b) => a + b

Call to Action

  • If this sounds good, I am offering to:
    • Implement the prototype and draft documentation.
    • Monitor community feedback and report back before ReScript 14.
  • Proposal team:
    • Greenlight: To try it as an experiment, see what the reception is.
    • Feedback: Suggest improvements or dealbreakers.
    • Veto: If the team feels this is misaligned, we can drop it - no hard feelings!

Final Note:

This is not about changing ReScript, but I think it is useful in helping onboard more developers to discover why it is great and helps users implement some of the most basic functions in their language in Rescript. If it does not work or is received poorly, we can kill it without any issue. But in any case, it is optional for use, and - as sugar - and would not anticipate any reason to affect backward compat or future ambitions for the language.


Next Steps:

  1. Discuss in the next core team meeting.
  2. If approved, I’ll open a PR for the prototype.
  3. Interact with the community via an RFC or blog post.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or compiler entry points. Start with the RFC discussion and the planned core team review; done would require an approved prototype and draft documentation, followed by community feedback.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, ocaml
Domain
compilers, developer-experience
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.