Description
I propose we add an alternative way of formatting lambda functions passed into HOFs as describe by the G-Research style guide.
The existing way of Fantomas deals with this problem is following the Microsoft style guide without any options.
Pros and Cons
The advantages of making this adjustment to Fantomas are following both style guides,
The disadvantages of making this adjustment to Fantomas are introducing a new setting and maintaining both choices.
Examples
List.collect (fun (a, element) ->
let path' =
path
|> someFunctionToCalculateThing
innerFunc<'a, 'b>
path'
element
(foo >> bar value >> List.item a)
shape
)
let mySuperFunction a =
someOtherFunction a (fun b ->
// doing some stuff her
b * b
)
Things to keep in mind:
- This seems to only have an impact on multiline constructs
- There can be arguments before and after the lambda.
- What with multiple lambdas?
- Desugared lambdas?
- Setting name?
Extra information
Estimated cost (XS, S, M, L, XL, XXL): L
Related suggestions: #1189
I think this feature cannot be implemented in one go. It will be a back and forward collaboration between trying things out in Fantomas and further polishing the style guide.
Affidavit (please submit!)
Please tick this by placing a cross in the box:
- I have read the Contribution Guidelines.
- I have searched both open and closed suggestions on this site and believe this is not a duplicate
Please tick all that apply:
- This is not a breaking change to Fantomas
- I or my company would be willing to help implement and/or test this
- This suggestion is part of the Microsoft style guide (please add a link to section if so)
- This suggestion is part of the G-Research style guide: Clarify lambda positioning G-Research/fsharp-formatting-conventions#10