-
Notifications
You must be signed in to change notification settings - Fork 464
Add pattern matching support for records with @optional
fields.
#5452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
cristianoc
added a commit
that referenced
this issue
Jun 20, 2022
This gives pattern matching that mimics expression constructor, where the variable by default is not optional. The generated code seems fine, thought the checks for exhaustiveness are not kicking in. See #5452
What will be an alternative to |
Same as with expressions. |
The expression, which was like this before this addition of patterns, looks like this: {x: 3, y: @option None} |
cristianoc
added a commit
that referenced
this issue
Jun 22, 2022
This gives pattern matching that mimics expression constructor, where the variable by default is not optional. The generated code seems fine, thought the checks for exhaustiveness are not kicking in. See #5452
cristianoc
added a commit
that referenced
this issue
Jun 22, 2022
This gives pattern matching that mimics expression constructor, where the variable by default is not optional. The generated code seems fine, thought the checks for exhaustiveness are not kicking in. See #5452
@optional
records.@optional
records.
@optional
records.@optional
fields.
cristianoc
added a commit
that referenced
this issue
Jun 22, 2022
This gives pattern matching that mimics expression constructor, where the variable by default is not optional. The generated code seems fine, thought the checks for exhaustiveness are not kicking in. See #5452
In master. |
mununki
pushed a commit
to mununki/rescript-compiler
that referenced
this issue
Jul 15, 2022
This gives pattern matching that mimics expression constructor, where the variable by default is not optional. The generated code seems fine, thought the checks for exhaustiveness are not kicking in. See rescript-lang#5452
29 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is follows on from #5423.
Example:
There's asymmetry between expressions and patterns.
Proposal: adopt for patterns the same convention used for expressions.
The example above now becomes:
And for catch-all:
| {y: _} =>
mean? A: it meansSome(_)
.| {y : @optional _ }
mean? A: it means_
.The text was updated successfully, but these errors were encountered: