Option for Stroustrup bracket style

[josh-degraw]

I propose we...
Add the ability to use Stroustrup bracket styling.

The existing way of Fantomas deals with this problem is ...
Use the existing bracket formatting styles, which are not commonly used in most mainstream programming languages.

Pros and Cons

The advantages of making this adjustment to Fantomas are ...
Allowing people to have more control over how they want to format their code, and having a more widely-used (esp. outside of F#) formatting style as an option.

The disadvantages of making this adjustment to Fantomas are ...
Adding another configuration option,technical complexity, and potential conflicts with existing formatting rules.

Examples

The officially recommended way to declare the following record type is as follows:

type PostalAddress =
    { Address: string
      City: string
      Zip: string }

For many, this style feels strange. My team and I prefer to use Stroustrup style e.g.

type PostalAddress = {
    Address: string
    City: string
    Zip: string
}

We like this because, among other reasons, it reduces the used horizontal space a little, makes it easier to reorder members, and just feels less messy. I am wanting to integrate fantomas to keep our code more consistent, and wanted to see if we could utilize that style for formatting at least record types.

I have used the fsharp_multiline_block_brackets_on_same_column=true that feels a little better:

type PostalAddress =
    {
        Address : string
        City : string
        Zip : string
    }

But it would be awesome to be able to format our code how we actually want it.

Extra information

Estimated cost (XS, S, M, L, XL, XXL):
L

Related suggestions: (put links to related suggestions here)

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 (please add a link to section if so)

For readers:

Please leave:

• 👍if you use Fantomas today and would enable this setting
• 🎉if you do not use Fantomas today and would start using it after this feature
• 👎if you use Fantomas today and would not enable this setting.

Remaining work

• Document the boundaries of the setting
• Rename the current setting (We can't keep the name Ragnarok)
• Investigate if fsharp_multiline_block_brackets_on_same_column should be implied as true automatically (superceded by Update config to accept a single option for multiline_bracket_style #2658) .
• Discuss/Implement Stroustrup: Type alias for anonymous record type #2179
• Revisit Elmish settings, Revisit Elmish code #2180

[nojaf]

Hello Josh, thank you for taking the time to write this elaborated request.
This, unfortunately, is exactly what we don't want in this project.

[nojaf]

Hello @josh-degraw, I'm having a change of heart when it comes to this request.
This is a complex subject, so I'll try to elaborate a bit on my motivations for re-opening this issue.

First, this issue has been requested multiple times in various shapes and forms.
Some people proposed it slightly different or on other platforms/repositories but they all are more or less after the same thing:

someExpression openingDelimiter
    multilineBodyExpression
closingDelimiter

From a technical point of view, it is quite challenging to get right and implement in the codebase.
It happens for a certain set of scenarios (which are open for interpretation) and there is no easy fix to capture them all.
That has for me been a good reason not to have this at all.

On the other hand, I get this request multiple times a year, for many years now.
I understand that people write code like this today and struggle to adapt to what Fantomas outputs.
It even serves a bit as a marker to see who is using Fantomas and who is not.
There is a lot of code in this style out there and I do recognise this fact.

Recently, I was inspired by some unrelated events and started working on a prototype for this.
You can see some progress in my somewhat secret ragnarok branch.
I got a chunk of it working and it is interesting to see where this goes.
The technical impact is what I expected and I do find some puzzling edge cases.

Besides the code part, another thing that I'm struggling with is determining the scope of this setting.
You listed some examples, but there is more to it from an AST point of view.
I'd like to bring a compelling and consistent story that works good enough for the community.
Not everybody's wishlist will be a part of the scope, but hopefully, it still might hold some value for most.
We need something sensible and determine where the boundaries lie.
Some things will make the cut, and some won't.
This should be documented as an architecture decision record.

Lastly, as this is not part of any style guide, I also don't want this setting to be a precedent that every request can make it into Fantomas.
Style should be discussed in the style guide.
Future style requests will most likely still be closed on sight if they have no backing by the style guide.
And yes, that will be a very unfair action considering that we might ship this current feature.

From a timeline point of view, this won't go overnight.
This will be a 4.7 feature and development in 4.6 still needs to wrap up.
Poke me on Gitter if you have any questions there.

All that said, I'm looking for help from the community.
Who is interested in contributing to this feature?

Happy to hear all your thoughts,

Florian

PS: tagging some people in no particular order:
@dsyme, @baronfel, @jindraivanek, @Smaug123, @stackedsax, @jgiannuzzi, @c-rindi, @auduchinok, @l3m, @ForNeVeR

[dsyme]

"somewhat secret ragnarok branch" - it's worth contributing just for that :)))

[baronfel]

The main tension I see here is between the project goals of:

• increasing adoption of the Fantomas tool in general,
• having a consistent set of defaults to use as a metric for what code style/formatting options should exist in Fantomas (in this case the F# Style Guide being the source of truth)

I 100% agree that this change should be done in the name of reducing barriers for using the tool for projects and ecosystems that don't want to abide by the F# Style Guide for whatever reason. My main worry is that without a firm enough set of guidelines for what is allowable in this new mode, the definition of the mode will be shaky and be more of a grab-bag of 'styles that XYZ people like' instead of a consistent design rule.

[JordanMarr]

I wouldn't do it to gain new users considering all the ongoing effort that would need to be poured into handling this with the new edge cases it would introduce. Going out of your way to take on more complexity for something that is outside of the official style guide seems like a bad move for you.

I can easily imagine someone voting "I would start using Fantomas if I could format my code this way" only to run into a new edge case bug and then quickly uninstalling it. 🤷‍♂️

[KathleenDollard]

A style is a set of decisions. One set is laid out in the Style Guide.

I understand @baronfel 's concern over "a grab bag of 'styles that XYZ people like', but I think it's worth exploring whether this request represents an alternate style guide. Any set of design decisions also needs to make sense together. Is this a single feature or a slightly different way to look at code? If the second, then this is almost by definition just the most obvious of a set of issues that would have to all be resolved to make Fantomas usable in that style.

I like the commitment Fantomas has to the Style Guide because it allows most F# to look the same and the value to reading code is significant. I like that this issue has a lot of friction to get it done, and the commitment that it isn't opening the door to a ton of other features, committing to very high friction for any future requests. The Style Guide support (and support for it in major editors) is what makes Fantomas Fantomas.

That said, if the community can help build this, it seems there is enough push (people not feeling they can use Fantomas), and the complexity can be reduced in design or otherwise made reasonable it seems OK to do.

[josh-degraw]

@nojaf I appreciate the additional look into this and willingness to potentially include it! I'd love to help contribute however I'm able.

[cartermp]

So I'm not inherently opposed to this, but I will note that the F# style guide currently states that these aren't okay, but rather the allman-style is: https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/formatting#formatting-record-declarations

From a technical standpoint it is the most flexible option, since there's no requirement to use with ... end to attach members to the record declaration.

That could change in the compiler of course, but as it stands, it's what I personally use for anything that isn't a 1-liner.

[twop]

PLEASE, that will be a game changer for me. I have to use

{
 a = 1
} 

all the time, because I found myself often adding or shuffling fields around which is extremely painful to do with the official style guide formatting (I use "copy line" shortcut that captures either { or } which I have to remove afterwards). With Stroustrup formatting it would be so much better!

[nojaf]

Hello all,

I'll try to address some comments below, wonderful to see this interaction.

@baronfel right on the money, enough guidelines will be required to indicate the scope of this setting. I don't think one simple rule will cover it, it will more or less be a set of rules when it applies and when it doesn't.

@JordanMarr you are correct as well, the folks that don't use Fantomas easily give up when one (little or large) thing isn't working as they hoped it would. Of all the people reacting 🎉, it is no guarantee they will become users after this setting.

@KathleenDollard I'm not sure this should be brought into the broader scope of an alternate style guide. It could just be documented as a way of dealing with a number of things instead of how the entire F# language specs should look like.
A bit similar to how the Elmish setting came to be. I'd like to avoid another style guide for the time being as that has the potential of introducing yet another sleeve of settings.
I'm more a fan of focusing on a good F# style guide where the vast majority of the community can get behind.

@josh-degraw many thanks for still being interested in contributing to this setting. I propose we organize some sort of kick-off meeting early next year.

@cartermp, you are correct that this setting would require with ... end in order to support members. Perhaps, to minimize the impact we can limit the scope of record type definitions to only allow Stroustrup formatting when there are no members/interfaces involved.

type V = {
    X : int
    Y : int
}

type W =
    {
        X : int
        Y : int
    }
    member this.Foo () = ...

Exceptions like this might be a necessary evil to keep the impact on the codebase to a minimum.

[olivercoad]

@cartermp can you explain the purpose for the style guide saying these aren't ok or point to some discussions about it? If there's not already been a a definitive decision, it might be worth opening an issue to add this style to the official style guide.

The best I could find is this, which feels a little underwhelming now considering the impact.

Also, I always dislike it when fantomas moves things to put the closing bracket on the same line as the last item, but it's worth mentioning that in some cases it does this even when the style guide doesn't.

[KathleenDollard]

@nojaf

My comment about an alternate style guide was unclear: I can't tell if this is a true one-off thing, or the tip of an alternate style guide iceberg. I do not think an alternate style guide, or the C# combine random features to create your own style, would benefit F#.