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

Allow undentation in method and constructor calls #931

Closed
4 of 5 tasks
toburger opened this issue Oct 25, 2020 · 8 comments
Closed
4 of 5 tasks

Allow undentation in method and constructor calls #931

toburger opened this issue Oct 25, 2020 · 8 comments

Comments

@toburger
Copy link

toburger commented Oct 25, 2020

Allow undentation in method and constructor calls

I propose we allow undentation in method and constructor calls without emitting a warning.

The existing way of approaching this problem in F# is that the arguments need to be placed more on the right side of the equal and the caller subject.

Sample:

This is possible today:

let x = System.DateTime(
            year = 2020,
            month = 12,
            day = 1)

also this:

let x =
    System.DateTime(
        year = 2020,
        month = 12,
        day = 1)

and:

let x =
    System.DateTime(
        year = 2020,
        month = 12,
        day = 1
    )

This gives a warning (FS0058):

let x = System.DateTime(
    year = 2020,
    month = 12,
    day = 1)

and likewise:

let x = System.DateTime(
    year = 2020,
    month = 12,
    day = 1
)

also this gives a warning (but is okay in constructors via dotnet/fsharp#6808):

let x = System.DateTime(year = 2020,
    month = 12,
    day = 1)

Sidenote:

Also this way of defining constructors or methods gives a warning:

type Foo (
    y: int,
    x: int) =
    member self.Bar(
        a: int,
        b: int) =
        ()

but this is okay:

type Foo (y: int,
    x: int) =
    member self.Bar(a: int,
        b: int) =
        ()

which was mentioned in #724 (comment) but apparently didn't made it into the PR...

Pros and Cons

The advantages of making this adjustment to F# is a visually more pleasant way of calling methods. Style and elegance is a very subjective view but it goes hand in hand with the relaxed indentation for lists and arrays introduced in F# 4.5 and the "elmish" style formatting.

The disadvantages of making this adjustment to F# are: (too much?) choices!

Extra information

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

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

@Swoorup
Copy link

Swoorup commented Oct 26, 2020

I have always been tripped up due to this. Now, I made peace realising F# doesn't like restrictions on number of columns, so just allowed it span across horizontally when creating class with large number of params/dependencies. This suggestion would make sense. And is common on C#/any C-style language as well.

@Tarmil
Copy link

Tarmil commented Oct 26, 2020

When I have a large number of arguments on a method or constructor, I usually write it like this, which doesn't give any warnings:

    member this.Method
        (
            arg1: int,
            arg2: int,
            arg3: int,
            arg4: int
        ) =
        body

but I agree that it would be nice to be able to put the opening parenthesis at the end of the previous line.

@charlesroddie
Copy link

@Tarmil the current problem with undentation of arguments in method or constructor definitions is covered by RFC FS-1070 but there is an incompleteness in the implementation.

@toburger do you think

let x = System.DateTime(
    year = 2020,
    month = 12,
    day = 1)

is superior to

let x =
    System.DateTime(
        year = 2020,
        month = 12,
        day = 1)

?

If not - and to me the latter looks more structured -, wouldn't a better solution be tooling to convert the former into the latter?

@toburger
Copy link
Author

toburger commented Oct 30, 2020

I would write it like:

let x = System.DateTime(
    year = 2020,
    month = 12,
    day = 1
)

I find this style very structured and this coding style aligns well with the existing "elmish" style formatting where lists are written like:

let xs = [
    "foo"
    "bar"
    "baz"
]

But as I already said it is a matter of personal taste.
I for myself don't mind requiring too much vertical space but horizontal space really bugs me and I find it hard to scan.

@charlesroddie
Copy link

I see. It does seem close to the list notation so that's a good comparison.

@dsyme
Copy link
Collaborator

dsyme commented Jul 5, 2021

Where is the proposed limit to the undentation? is it 1-space indentation from the let? e.g. consider these:

let x = System.DateTime(
 year = 2020,
 month = 12,
 day = 1
)

and this (ugh)

let x = System.DateTime(
year = 2020,
month = 12,
day = 1)

and this (ugh)

let f() =
    let x = System.DateTime(
 year = 2020,
 month = 12,
 day = 1
)

In general the let form a hard line :)

@dsyme
Copy link
Collaborator

dsyme commented Aug 24, 2021

Completed in preview dotnet/fsharp#11772

@dsyme dsyme closed this as completed Oct 13, 2021
@dsyme
Copy link
Collaborator

dsyme commented Oct 13, 2021

Completed in F# 6

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

No branches or pull requests

6 participants