Newline inconsistency in object expression

Code

let helpers =
    { new IDecoderHelpers<JToken> with
        member _.isString jsonValue =
            not (isNull jsonValue) && jsonValue.Type = JTokenType.String
        member _.asFloat jsonValue = jsonValue.Value<float>()
        member _.asInt jsonValue = jsonValue.Value<int>()
        member _.getObjectKeys jsonValue =
            jsonValue.Value<JObject>().Properties()
            |> Seq.map (fun prop -> prop.Name)
        member _.getField(fieldName: string, jsonValue: JToken) = jsonValue[fieldName]

    }


let helpers2 =
    { new IDecoderHelpers<JToken> with
        member _.anyToString jsonValue =
            if isNull jsonValue then
                "null"
            else
                use stream = new StringWriter(NewLine = "\n")

                stream.ToString()
    }

Result

let helpers =
    { new IDecoderHelpers<JToken> with
        member _.isString jsonValue =
            not (isNull jsonValue) && jsonValue.Type = JTokenType.String

        member _.asFloat jsonValue = jsonValue.Value<float>()
        member _.asInt jsonValue = jsonValue.Value<int>()

        member _.getObjectKeys jsonValue =
            jsonValue.Value<JObject>().Properties() |> Seq.map (fun prop -> prop.Name)

        member _.getField(fieldName: string, jsonValue: JToken) = jsonValue[fieldName]

    }


let helpers2 =
    { new IDecoderHelpers<JToken> with
        member _.anyToString jsonValue =
            if isNull jsonValue then
                "null"
            else
                use stream = new StringWriter(NewLine = "\n")

                stream.ToString() }

Problem description

I believe it would be better if there was a new line between each member, this would make the code more consistent. I think that if all the member are single line then not having a new line is fine.

Also, the placement of the trailing } is not always placed on a new line. I don't know what triggers that because in my project, I have a similar code as the member _.anyToString jsonValue = method and the } is placed on a new line and indented under the leading {.

Extra information

The formatted result breaks my code.
The formatted result gives compiler warnings.
I or my company would be willing to help fix this.
I would like a release if this problem is solved.

Options

Fantomas main branch at 1/1/1990

    { config with
                AlternativeLongMemberDefinitions = true
                MultiLineLambdaClosingNewline = true }

_{Did you know that you can ignore files when formatting by using a .fantomasignore file?}
_{PS: It's unlikely that someone else will solve your specific issue, as it's something that you have a personal stake in.}

Hi there,

I believe it would be better if there was a new line between each member, this would make the code more consistent. I think that if all the member are single line then not having a new line is fine.

This is a topic for the style guide.

Also, the placement of the trailing } is not always placed on a new line.

In helpers, } is placed on a new line because it had a blank line before it. That was preserved from the original code. This works as expected.

In helpers, } is placed on a new line because it had a blank line before it. That was preserved from the original code. This works as expected.

You say that } is placed on a new line because there is blank line before however the following snippet results in the same formatting:

let helpers =
    { new IEncoderHelpers<JToken> with
        member _.encodeUInt32 value = JValue(box value) }

let helpers2 =
    { new IEncoderHelpers<JToken> with
        member _.encodeUInt32 value = JValue(box value) 
    }

Result

let helpers =
    { new IEncoderHelpers<JToken> with
        member _.encodeUInt32 value = JValue (box value)
    }

let helpers2 =
    { new IEncoderHelpers<JToken> with
        member _.encodeUInt32 value = JValue (box value)
    }

In both cases the } is pushed to a new line under the leading {.

Options

[*.{fs,fsx}]
max_line_length = 80
fsharp_space_before_uppercase_invocation = true
fsharp_alternative_long_member_definitions = true
fsharp_multi_line_lambda_closing_newline = true
fsharp_bar_before_discriminated_union_declaration = true
fsharp_multiline_bracket_style = stroustrup
fsharp_keep_max_number_of_blank_lines = 2

@josh-degraw

Oh, I see. Your original report did not mention fsharp_multiline_bracket_style = stroustrup.

Stroustrup cannot be applied in absolutely every situation. I was convinced that

let x = { new System.IDisposable with
  member _.Dispose () = ()
}

was invalid code. (Producing an offset error).
In certain situations it can lead to invalid code.

This does not seem the case.
I am pretty sure we decided against this for object expressions.
@josh-degraw does this ring a bell?

So, we could double-check whether is indeed possible for object expressions.
If so, someone adds support for it. If not, we document that stroustrup cannot be used absolutely everywhere.

Yeah that's sounds correct to me as far as what we did. However, wouldn't something like this be valid if we wanted to more strictly apply Stroustrup here?

let x = { 
    new System.IDisposable with
        member _.Dispose () = ()
}

This would be how I would expect Stroustrup style to be applied here.

If it always leads to valid code, I'd be ok with this.
It really rings a bell that this wasn't the case.
Can't immediately find any prior art though.

It is mentioned in the style guide. Guess this is possible.

Oh, I see. Your original report did not mention fsharp_multiline_bracket_style = stroustrup.

Ah yes sorry, I have a hard time finding which settings I have setup locally and not in the online tool.

🤖 This is an automated response from Repo Assist.

I tested the examples from this issue against the current main branch with fsharp_multiline_bracket_style = stroustrup.

Closing } placement — the inconsistency reported here appears to be fixed. Both helpers (multiline body ending cleanly) and helpers2 (multiline body with use/let-in tail) now consistently place } on its own line:

let helpers2 =
    { new IDecoderHelpers with
        member _.anyToString jsonValue =
            if isNull jsonValue then
                "null"
            else
                use stream = new StringWriter(NewLine = "\n")

                stream.ToString()
    }

Blank lines between adjacent single-line members — as noted by @nojaf above, the question of blank lines between interface members is a style-guide question. The current behaviour is:

A blank line is inserted before multiline member definitions (consistent with how Fantomas formats class member lists generally)
Adjacent single-line members are not separated (no blank line between asFloat and asInt)

This matches the Microsoft F# formatting guide for object expressions, which does not prescribe blank lines between single-line members.

If you are still seeing } on the wrong line, or another inconsistency, with a current Fantomas version, please share a minimal repro and the Fantomas version number — I would be happy to investigate further. Otherwise this issue may be safe to close or moved to discussion if you'd like to pursue the blank-line-between-all-members behaviour upstream.

Generated by 🌈 Repo Assist at {run-started}. Learn more.

To install this agentic workflow, run
gh aw add githubnext/agentics/workflows/repo-assist.md@1f672aef974f4246124860fc532f82fe8a93a57e

Bump the dotnet-sidecars group with 6 updates (#257)

Bump the packages group with 5 updates (#106)

Bump the packages group with 6 updates (#84)

Bump the packages group with 10 updates (#280)

Navigation Menu

Repository navigation

Newline inconsistency in object expression #2990

Code

Result

Problem description

Extra information

Options

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Newline inconsistency in object expression #2990

Description

Code

Result

Problem description

Extra information

Options

Activity

nojaf commented on Nov 18, 2023

MangelMaxime commented on Nov 18, 2023

nojaf commented on Nov 18, 2023

josh-degraw commented on Nov 18, 2023

nojaf commented on Nov 18, 2023

nojaf commented on Nov 18, 2023

MangelMaxime commented on Nov 18, 2023

github-actions commented on Apr 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions