Style guide lambda

[nojaf]

Hi @dsyme, in order to follow up on dotnet/docs#25207, I've implemented the change in Fantomas to have a better idea of what the impact would be.

I'll explain the high-level gist of the implementation and perhaps you confirm if I understood the guidance correctly.
So, firstly I believe the guidance was focused around function applications where a lambda (be it SynExpr.Lambda or SynExpr.MatchLambda) is the last argument.

I've captured the nested SynExpr.App in an active pattern (|AppWithLambda|_|) and applied new logic to that exact shape of SynExpr.
First, if the expression is short, we try to put it in one line.

functionName arg1 arg2 arg3 (fun arg4 -> bodyExpr)

If the max_line_length is crossed or the body is multiline, we apply alternative formatting.
There, we first check if the function name and arguments until the arrow of the lambda fit on the remainder of the line.

So imagine something like:

functionName arg1 arg2 arg3 (fun arg4 ->

If this all still fits on the current line, we write it as such and indent the body one level on the next line.

functionName arg1 arg2 arg3 (fun arg4 ->
    bodyExpr)

In case this doesn't fit all argument go on the next line with one level of indent:

functionName 
    arg1 
    arg2 
    arg3 
    (fun arg4 ->
        bodyExpr)

This makes a lot of sense to me, especially when arg1, arg2 or arg3 are multiline themselves.

In case the last argument is SynExpr.MatchLambda we try the same thing:

functionName arg1 arg2 arg3 (function
    | Choice1of2 x
    | Choice2of2 y)

Or if the max_line_length is crossed:

functionName 
    arg1 
    arg2 
    arg3 
    (function
     | Choice1of2 x
     | Choice2of2 y)

Notice there is no extra indent on the line after the function keyword, the clauses do align with the function keyword.

If you look at the implementation, you will see the MultiLineLambdaClosingNewline setting.
This is to cope with the GR style guide, as they do things differently with lambdas.
So, don't mind that 😊.

Let me know what you think, it would be a great help if you could take a look at the expected results in the unit tests.
Thanks in advance!

[dsyme]

I looked through the test cases and in almost every case it looks like an improvement to me.

[nojaf]

Thanks Don!

[dsyme]

@nojaf Should we merge this? Thanks

[nojaf]

Yes, I've been on holiday for some time so that is the reason why this is has been lingering a bit.
The goal is to release this soon as alpha and update the online tool to target the 4.6 branch for the prerelease mode.

One thing that somewhat puzzles me is the disappearance of the FCS 40 prerelease. It is unlisted on NuGet.
Any ideas on that @dsyme? See dotnet/fsharp#11926

[dsyme]

@nojaf Am asking @KevinRansom about the disappearence of the pre-release

[KevinRansom]

Sorry, I unlisted it by mistake, there are some we mean to list, and some we don't mean to list and because it's hard to tell which set something belongs to I unlisted it.

However, we have decided to eliminate the need to ship unlisted FSharp.Compiler.Service packages, so from now now on the listing status shouldn't change.

Sorry about the inconvenience, and thanks for pointing it out.

Kevin