Refactor how computation expressions are formatted #840
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem with the current implementation was that the
SynExpr.LetOrUseBang
could be part of a nestedSynExpr.LetOrUse
expression and that would mean that the first let bindings inside a computation expression are formatted somewhere else.That made it hard to determine whether the first
let!
needed a newline before it.In my proposed solution, I check whether the expression (inside the CompExpr) contains something related to a bang keyword
let!, return!, and!, etc.
, if that is the case collect all expressions (and especially the let bindings).Once all expressions are collected, merged them together using the
colWithNlnWhenItemIsMultiline
helper function.This fixes #838 and should make Computation Expressions, in general, adhere to the rules when we add newlines between expressions.