Omit explicit returns where possible

[natikgadzhi]

Motivation

A separate formatting PR to make space for @Matejkob and @ahoppen and @kimdv to review how our codebase would look with omitting return statements where it's possible, a follow-up to #2136. Since this topic might spawn a longer discussion, I've put that rule in a separate PR.

Changes

• Adds OmitExplicitReturns swift-format rule to .swift-format
• Formats the codebase
• Follow-up to Order all imports lexicographically #2145, but in a separate commit for easier review.

[kimdv]

Personally I'm not in favor of omitting returns.
I think it makes it harder to read code.
I known that the SwiftSyntaxBuilder in code gen don't use, just like SwiftUI. But for me it makes sense and is fine.

But a normal variable or function need a return IMO

[natikgadzhi]

I'm only a beginner in Swift, but so far omitting returns feels good in:

• one-line closures
• result builders
• one-line / one-statement dynamic property bodies
• perhaps functions that don't have any control flow in them and are very short (one statement)

But, I agree that making this a mandated format might not work well in situations where explicit return keywords make the code much more readable.

While a lot of swift-syntax code are small functions, and they look pretty nice without return to a newcomer like myself, I don't have a strong opinion, and don't have the experience to back up my opinions even if I had one.

So, that PR is for demonstration purposes. If we chose to enable the rule, we can do so at any point in the future.

[xedin]

Just a general note about return omission. As per proposal, return statements could only be omitted if body constitutes of a single expression, anything more context always requires an explicit return.

[natikgadzhi]

@ahoppen, I think we should probably close this for now? We know this happened, and if we want to return to that — the PR will be here. @Matejkob, good with you too?

[Matejkob]

I would personally advocate for merging. I might be a bit biased since I'm accustomed to omitting the return keyword in my projects. I also appreciate the consistency it brings. We already have numerous instances where return is omitted, so implementing this rule would contribute to overall codebase consistency. However, I'm just a random individual and don't really feel in a position to strongly push for my approach.

[natikgadzhi]

However, I'm just a random individual and don't really feel in a position to strongly push for my approach.

Big same here.

[natikgadzhi]

I've rebased this PR so we can review this with ordered imports and other improvements merged in.

It's growing on me, to be honest. Should I perhaps start a topic in swift forums to pitch this and get more feedback from the community, @ahoppen?

[ahoppen]

I’ll gather some feedback on this internally and come back to you in the next week-ish. I’m also very hesitant to merge this as-is.

[ahoppen]

I just had another conversation about this and we don’t want this change for now. If there was an official Swift API design guideline to follow regarding when to omit return, we should definitely adopt it in swift-syntax but for now we believe that enforcing the omission of return in general makes the code less readable.