Skip to content
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

fsharp_space_before_uppercase_invocation=true breaks method calls #1437

Closed
1 of 3 tasks
lydell opened this issue Feb 8, 2021 · 8 comments · Fixed by #1439
Closed
1 of 3 tasks

fsharp_space_before_uppercase_invocation=true breaks method calls #1437

lydell opened this issue Feb 8, 2021 · 8 comments · Fixed by #1439

Comments

@lydell
Copy link

lydell commented Feb 8, 2021

Issue created from fantomas-online

Code

Log.Logger <-
    LoggerConfiguration()
        .Destructure.FSharpTypes()
        .WriteTo.Console()
        .CreateLogger()

Result

Log.Logger <-
    LoggerConfiguration ()
        .Destructure.FSharpTypes ()
        .WriteTo.Console ()
        .CreateLogger ()

Problem description

The output code causes the compilation errors:

error FS0039: The type 'Unit' does not define the field, constructor or member 'Destructure'.
error FS0501: The object constructor 'LoggerConfiguration' takes 0 argument(s) but is here given 1. The required signature is 'LoggerConfiguration() : LoggerConfiguration'.

Extra information

  • The formatted result breaks by code.
  • The formatted result gives compiler warnings.
  • I or my company would be willing to help fix this.

This seems to have been introduced in 4.4.0-beta-003.

Options

Fantomas Master at 02/05/2021 16:56:34 - 0cbe3df

    { config with
                SpaceBeforeUppercaseInvocation = true }
@knocte
Copy link
Contributor

knocte commented Feb 9, 2021

Wow, shouldn't this be an F#-compiler bug?

nojaf added a commit that referenced this issue Feb 9, 2021
* Only add a space at the end of a long nested DotGet chain. Fixes #1438. Fixes #1437.

* Bump to 4.4.0-beta-005.
@auduchinok
Copy link
Contributor

auduchinok commented Feb 10, 2021

Wow, shouldn't this be an F#-compiler bug?

@knocte Nope, it's per-spec. The application without space inside has a higher precedence than a normal one, otherwise it'd be very hard to come up with rules for applications and access-via-dot syntax, and cases like the following ones would be messed up:

f(x, y).P
f (x, y).P

@knocte
Copy link
Contributor

knocte commented Feb 10, 2021

cases like the following ones would be messed up:

hey thanks for the info, but what do you mean exactly by that example? how is f (x,y).P different than f(x,y).P? genuinely curious

@auduchinok
Copy link
Contributor

auduchinok commented Feb 10, 2021

how is f (x,y).P different than f(x,y).P?

Here the first example applies (x, y).P to f, while the second one accesses P member on the result of f(x, y).

@knocte
Copy link
Contributor

knocte commented Feb 10, 2021

Truly interesting, I guess I hadn't come up with this because the fluent style is less visible in functional languages (because returning the same element in each call attracts a programming style that involves mutability). And what would f (x,y) .P be?

@auduchinok
Copy link
Contributor

auduchinok commented Feb 10, 2021

Well, the tuple example is not very correct, and my point needed a syntax example where parens were required. 🙂
Imagine accessing member on a function application result like this:

f(g x).P
f (g x).P

@auduchinok
Copy link
Contributor

auduchinok commented Feb 10, 2021

And what would f (x,y) .P be?

f (x,y) .P is the same as f (x,y).P, since dot access has higher precedence than "normal" (i.e. with space) application.

The operators and applications part of this table below can give more info: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/#operator-precedence

@knocte
Copy link
Contributor

knocte commented Feb 10, 2021

Ok thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants