Closed OceanOak closed 1 month ago
This PR updates match_case to work in the following way: if the rhs is an expression, it should be written in an indented block, or wrapped in parentheses
Why? Ideally, I wouldn't have to put a simple fn call in the next line or wrap in parens. I'm a bit confused what prompted this PR.
As a side-note, tuple_literal
might be a simple_expression
?
edit: record-update might be OK as a simple_expression, too (the {} at either end wrap the expr contents well)
edit: maybe qualified_const_name
too?
Why? Ideally, I wouldn't have to put a simple fn call in the next line or wrap in parens. I'm a bit confused what prompted this PR.
Trying to parse the following is what prompted this PR
let parseConst (node: ParsedNode) : Result<WrittenTypes.Const, WrittenTypes.Unparseable> =
match node.typ with
| "consts" ->
match node.children with
| [ constNode ] -> parseConst constNode
| _ -> createUnparseableError node
This ^ was parsing in a very odd way, and the issue only happens when we have nested match_exprs
within a fn_decl
But you're right, I restricted it more than necessary. Adding support for an indented block in a match_case was enough to fix it.
As a side-note, tuple_literal might be a simple_expression? edit: record-update might be OK as a simple_expression, too (the {} at either end wrap the expr contents well) edit: maybe qualified_const_name too?
yes, those seems safe to move, thanks.
No changelog