Skip to content
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

Computation expresions formatting #19

Open
xperiandri opened this issue Mar 18, 2021 · 9 comments
Open

Computation expresions formatting #19

xperiandri opened this issue Mar 18, 2021 · 9 comments

Comments

@xperiandri
Copy link

Original issue fsprojects/fantomas#1526
This repository does not provide any sample of computation expressions formatting.

I propose to define

let asyncDoSomething () = async {
    do! asyncSomething ()
    let! result = asyncGetSomething ()
    ()
}

let items = seq {
    "item1"
    "item2"
}

as a standard formatting option.

Currently Fantomas changes the code above to

let asyncDoSomething () = async {
    do! asyncSomething ()
    let! result = asyncGetSomething ()
    ()
}

let items = seq {
    "item1"
    "item2"
}
@Smaug123
Copy link
Contributor

This one's a bit of a poser. I think I exclusively use:

let items =
    seq {
        yield "item1"
        yield "item2"
    }

However, in the case of an async function only, I use the following, with async on the same line as the equals:

let foo () : Async<int> = async {
    let! blah = Async.Sleep 100.
    return 3
}

If it's a variable, I'd often do the following:

let somethingElse () : int =
    let bar =
        async {
            let! blah = Async.Sleep 100.
            return 3
        }
    bar |> Async.RunSynchronously

I'll write up a PR to this effect, and run it past the GR team.

@nojaf
Copy link
Contributor

nojaf commented Mar 21, 2021

Having that exception only for async seems quite inconsistent.
Not only amongst computation expressions but currently the guide has no examples where a multiline let binding expression still starts after the equal sign.
I'd like to point out that this would be an exception where 62 other types of syntax expression always start on the next line.

@Smaug123
Copy link
Contributor

I checked with the rest of the team and we're happier staying consistent, everything on a newline. I'll update my PR.

@Smaug123
Copy link
Contributor

(The reason for the exception is that this is the only computation expression in common use where the intent is to be "just like a normal function".)

@xperiandri
Copy link
Author

xperiandri commented Mar 21, 2021

It can be applied the same to any computation expression.
As I understand .editorconfig allows to specify any values and separate them by comma.
It would be nice to have a setting like computation_expressions_to_keep_on_same_line = async, asyncResult
This way anyone can be happy with the styling 🙂

@xperiandri
Copy link
Author

The only case when the next line must be forced regardless of the setting is when computation expression passed to the left pipe

let somethingElse () : int =
    async {
        let! blah = Async.Sleep 100.
        return 3
    }
    |> Async.RunSynchronously

By the way this constructs (with a single pipe) I always write as

let somethingElse () : int = Async.RunSynchronously <| async {
    let! blah = Async.Sleep 100.
    return 3
}

@Smaug123
Copy link
Contributor

To be clear, the G-Research/fsharp-formatting-conventions repo is primarily here to record G-Research's style guidelines; Fantomas uses it as a reference, because Fantomas supports G-Research's style guidelines as well as Microsoft's.

I am only an imperfect vessel for GR's style, and it turns out I was wrong about what the team wanted, so I amended my original PR to completely remove the async special case.

@dbarbashov
Copy link

My team and I would really appreciate this code style to be included as an option. We have 1000+ usages of async on the same line (and some of the other CEs) and we really can't bear with the amount of indentation that default code style generates.
Actually it seems like it is the only blocker for using Fantomas with our project.
I totally understand that this repo is about GR, but it seems that this is the only place to discuss unorthodox code style suggestions for Fantomas.

@nojaf
Copy link
Contributor

nojaf commented Dec 23, 2021

Hello, there might be room for this in fsprojects/fantomas#1408.
Please join the discussion over there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants