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
Consider making fsharp_experimental_stroustrup_style
apply independently of fsharp_multiline_block_brackets_on_same_column
#2425
Comments
Hello, thank you for bringing this up.
That is not entirely true, there are situations when Stroustrup isn't documented I see. I would accept a PR for that but as we are already in beta I don't have any desire to change the public API. Lastly, as the setting is forbidden fruit I can very much live with the very minor UX inconvennience. |
That's a fair counter example, although it's worth noting that that's an exception to the style rule. My main point with that was that it can be confusing to have to specify putting brackets on the same column when the main purpose of Stroustrup style is to have them on different columns, so having the effects of SameColumn apply by default would result in less confusion imho without changing any of the public API.
That's actually kind of my main point, that they're not currently independent. If both settings have to be checked for one to apply, one is very dependent on the other. What I'm suggesting is to make it so that turning on the Stroustrup setting works independently, whether or not you've enabled any other settings. A better word choice on my part probably would have been to say that the effects of the same column rule (those that would still be applied such as your example above) should be implied and enabled if Stroustrup is checked, rather than only if both settings are enabled manually. EDIT: Worth noting that this was actually a point you mentioned in the original stroustrup issue:
This is essentially the summation of what this issue is bringing up, and I'm just voting in the affirmative :) |
fsharp_experimental_stroustrup_style
take precedence over fsharp_multiline_block_brackets_on_same_column
fsharp_experimental_stroustrup_style
apply independently of fsharp_multiline_block_brackets_on_same_column
The more I think about it, the more I think it makes the most sense to use a single flag for bracket formatting, since although Stroustrup currently relies a lot on the Allman implementations under the hood, from an end user perspective, "bracket style" can be seen as a mutually exclusive decision between a specific set of options, which I think is why a bunch of folks have gotten confused by the fact that Stroustrup currently requires 2 settings. In this case, it could be represented by something like: type BracketStyle =
| Classic
| Allman
| Stroustrup My gut tells me that this might also make the implementation points a bit clearer and potentially simpler because of exhaustive type checking. I recognize though that this would require a lot of plumbing changes, but I'm willing to toy around with it and see if it's feasible, if it's a direction you're willing to entertain. |
I'm willing to go there eventually but not in the short term. Sidenote: We also deliberately didn't call |
Fair enough, I actually agree since it's not "true" Allman (it could also be argued that it's not "true" Stroustrup either haha). But yeah I messed around with it a bit yesterday and I think for a real implementation I would do something like: type MultilineBracketStyle =
| Classic
| Aligned
| ExperimentalStroustrup For what it's worth, I had some time yesterday and I was able to get an implementation fully working, and I do think at least from my perspective it made it a lot easier to understand the implementation differences between the 3 bracket styles. The only major task I still would need to do would be to add a bit of logic to keep the editorconfig parsing backwards compatible, but the actual implementation required fewer changes than I expected to get all the formatting tests to pass. I think it can be done in a way that retains full backwards compatibility to avoid needing a breaking change, but still adds some tangible benefits to both the implementation and the end user sides especially in the form of clarity. |
Fix available in v5.2.0-beta-001 |
As mentioned in a comment in #2413:
Currently, to use the experimental Stroustrup setting you need to enable two flags. Other than the potential issue of not knowing you need to enable two flags, the
MultilineBlockBracketsOnSameColumn
is technically inaccurate when using the Stroustrup style, as by definition the brackets are on different columns.I propose that:
fsharp_experimental_stroustrup_style
is enabled,fsharp_multiline_block_brackets_on_same_column
should be treated as redundant and relevant logic should be applied automatically whether it's present or not.MultilineBlockBracketsOnSameColumn
should only need to check if the Stroustrup setting is enabled,MultilineBlockBracketsOnSameColumn
, but not otherwise, should check if either flag is present instead of only being applied ifMultilineBlockBracketsOnSameColumn
is true.Alternatively, it might make sense to have a different flag to encapsulate the possible bracket styles (e.g.
stroustrup
,allman
,classic
, or whatever is most accurate). Admittedly a change like that could balloon out in logic handling, but for configuring the code it could make it much more straightforward to only need one flag to represent all potential bracket indentation styles.Regardless, IMHO the biggest issue with the current api is mainly the fact that
MultilineBlockBracketsOnSameColumn
is factually incorrect when Stroustrup style is applied, so I think an adjustment is at least worth discussing due to the potential confusion it could cause.The text was updated successfully, but these errors were encountered: