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

Add configuration option for adding ) on a new line #902

Open
kimdv opened this issue Dec 15, 2024 · 7 comments
Open

Add configuration option for adding ) on a new line #902

kimdv opened this issue Dec 15, 2024 · 7 comments

Comments

@kimdv
Copy link
Contributor

kimdv commented Dec 15, 2024

Current if we in out project have the formatter formatting

throw DecodingError.dataCorruptedError(in: container, debugDescription: "Unknown date format: \(dateString)")

It results in

throw DecodingError.dataCorruptedError(
    in: container, debugDescription: "Unknown date format: \(dateString)")

But it would be nice if it was possible to configure it to do this

throw DecodingError.dataCorruptedError(
    in: container, debugDescription: "Unknown date format: \(dateString)"
)
@kimdv
Copy link
Contributor Author

kimdv commented Dec 15, 2024

If it's something that we want to add, I can look into it.

@ahoppen
Copy link
Member

ahoppen commented Dec 15, 2024

Synced to Apple’s issue tracker as rdar://141514256

@ahoppen
Copy link
Member

ahoppen commented Dec 15, 2024

I don't remember which exact setting it is, but we definitely have the comment on a new line in the Swift-syntax and SourceKit-LSP repos - it might be lineBreakBeforeEachArgument. Is that what you want as well or do you want to have multiple arguments on the same line but the closing parenthesis on a new line.

@kimdv
Copy link
Contributor Author

kimdv commented Dec 16, 2024

I think it's because we have max line length I think. So we accept length of 120. And if it exceeds that, we break into newline.

So as long as all arguments can be on a single line, all good.

@allevato
Copy link
Member

I received the exact opposite request from someone else recently—an option to always force the closing paren onto the previous line.

I'm inclined to say I'm not particularly keen to add this right now; I've stated on previous issues that I don't particularly find it compelling to add finely-grained knobs for every possible preference that users might want. Ensuring that the interactions between every different knob and various syntactic constructs work properly becomes a combinatorially difficult implementation and testing problem, and I'm not sure changes like this (in either direction) necessarily buy their weight when it comes to rationalizing that complexity.

@kimdv
Copy link
Contributor Author

kimdv commented Dec 18, 2024

@allevato I see your point and understand.

It's just because with linebreakbeforeeachargument set to false, I would expect, and this is how I read the documentation, that if line length is exceeded then linebreakbeforeeachargument will be applied.

And with the case above I don't believe it is.
So with the example above, I would expect

throw DecodingError.dataCorruptedError(
    in: container, 
    debugDescription: "Unknown date format: \(dateString)"
)

@allevato
Copy link
Member

lineBreakBeforeEachArgument's false behavior is described as:

If false, arguments will be laid out horizontally first, with line breaks only being fired when the line length would be exceeded.

This means that it will horizontally pack arguments until the line is full and only if/when it reaches that point will it insert a line break before continuing to render arguments. The only other invariant is that if the whole argument list doesn't fit, then a line break is inserted before the first one; it is never allowed for an argument to "hang" off the same line where the function call started.

Some examples:

someFunction(foo)
someFunction(
  foo, bar)
someFunction(
  foo, bar, baz,
  quux)

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

No branches or pull requests

3 participants