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

Don't indent closing paren where possible #1101

Conversation

brandonchinn178
Copy link
Collaborator

Currently, multiline tuples in function arguments look like this:

f
  ( a,
    b,
    c,
    ) = _

It would look a bit nicer if the closing paren was not indented like

f
  ( a,
    b,
    c,
  ) = _

This doesn't work in all cases; specifically, it's a syntax error to do this in case expressions. But we can do this in all of the places where it makes sense.

I had to do this anyway for Fourmolu (it looks even more egregious with leading commas), and figured I'd send a patch upstream, in case y'all want it.

@amesgen
Copy link
Member

amesgen commented Mar 23, 2024

FTR: There are also other cases that work very similarly; if we go with this PR, we should probably do the same for them for consistency (not asking you to do that here 😅).

Some examples, showing multi-line patterns as a regular argument, and in a \case pattern (where we need extra indentation for the closing part).

InputOrmolu 0.7.4.0 output
Lists
foo
  [ x
  ] = x

bar = \case
  [ x
    ] -> x
foo
  [ x
    ] = x

bar = \case
  [ x
    ] -> x
Unboxed tuples
foo
  (# x
  #) = x

bar = \case
  (# x
    #) -> x
foo
  (#
    x
    #) = x

bar = \case
  (#
    x
    #) -> x

While writing this, it seems clear that a small advantage of the current way of always adding the extra indentation to the closing bracket even when unnecessary is that you can refactor a "normal" pattern to e.g. a \case without being confused why your code suddenly doesn't parse anymore. However, I don't know how often this actually occurs, it might not be very relevant.

@brandonchinn178
Copy link
Collaborator Author

Sure, it is nice to do the one thing that works in all cases. But there is precedence; I think we add some extra indentation specifically for do blocks and such, so it's not crazy to make that exception here too. Up to you

@brandonchinn178
Copy link
Collaborator Author

@amesgen Any thoughts on merging this?

@brandonchinn178 brandonchinn178 force-pushed the bchinn-multiline-tuple-args branch from fcae2a6 to a27fcb1 Compare May 31, 2024 07:03
@mrkkrp
Copy link
Member

mrkkrp commented May 31, 2024

I'm not sure about this one. It deviates from the status quo and makes the code more complex. Both effects are not exactly welcome per se but can be accepted if there is something in the change that makes it worth the trouble. So, it boils down to the question "how important/desirable is this change?"

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

Successfully merging this pull request may close these issues.

3 participants