Newline after "bang" keywords in computation expressions.

[fahrenq]

Dear maintainers,

Recently updated my Rider which apparently included the new version of Fantomas.

I found this behavior to be very strange:

let f =
  async {
    // Without binding newline after assignment sign preserved, which is expected behavior
    let r =
      match 0 with
      | _ -> ()

    return r
  }

let f2 =
  async {
    // When binding, newline force-removed, which makes the whole expression
    // on the right side to be indented.
    let! r = match 0 with
             | _ -> () |> async.Return

    return r
  }

And it also true for all other "bang" methods in computation expressions (return!, do!, etc.)
Please note it's not exclusive to pattern matching on the right side. I just chose it as an example from my production code, but in fact, any code block gets indented.

You can see more examples here.

While it doesn't look all that scary with examples above, production code has really weird looking indentation that's hard to work with.

I'm ready to contribute and adjust things above by myself, I just want some insights on why was this rule added in the first place? Should we make this behavior optional?

Thanks!

[nojaf]

Hello @fahrenq, the new version of Fantomas has nothing to do with the way bangs are formatted.
It has been like this since I've picked the project up and as far as I can tell it has no real deliberate reason.

The first thing that comes to mind is that the AST will be different with and without ! and so things might have diverged in the CodePrinter file.

I'm ok with changing the current behaviour as it would be better if it is matching the style without !.
Please add new unit tests in https://github.com/fsprojects/fantomas/blob/master/src/Fantomas.Tests/ComputationExpressionTests.fs to cover all scenarios and check out our contribution guide.

Let me know if you need any further help, I'm also around on the F# Foundation slack if that helps.

[fahrenq]

Thank you very much, I will check it out and will try to resolve it.
Happy New Year :)

[drhumlen]

We have a lot of computation expressions in our codebase, so I see this formatting inconsistency all the time too. +1'ed

I much prefer the formatting of the ordinary lets btw if there's any doubt. The formatting for let! leads to a ton of empty space with some very narrow formatting around column ~100 which is really hard to read and looks weird.

Hoping for a fix for this soon 😄