wrapConditionalBodies incorrectly wraps Swift 5.9+ if expressions

[KYHyeon]

Summary

The wrapConditionalBodies rule's help text describes its scope as "inline conditional statements", but it currently also wraps Swift 5.9+ if expressions, which is unintended behavior.

Reproduction

// Input
.contains { if case .cancelled = $0 { true } else { false } }
let isX = if condition { true } else { false }

// Output (current — undesired)
.contains { if case .cancelled = $0 {
    true
} else {
    false
} }
let isX = if condition {
    true
} else {
    false
}

Verified with SwiftFormat 0.60.1:

swiftformat --rules wrapConditionalBodies --swift-version 6.0 <file>

Background

The rule was introduced in #989 (August 2021), before Swift 5.9 introduced if expressions (September 2023). This case was likely never considered.

SwiftLint's equivalent rule conditional_returns_on_newline naturally avoids this — it only triggers when the body contains a return statement, so if expressions are unaffected by design.

Suggested Fix

Skip wrapping when the if is used as an expression. Two cases to detect:

Case 1 — assignment context (let x = if ...):
Already detectable via the existing isConditionalAssignment(at:) helper.

Case 2 — closure/function body expression (.contains { if ... { true } else { false } }):
Harder to detect without type information. One possible heuristic is checking that all branches are exhaustive (else branch present) and no branch body starts with return, but this has edge cases. Open to suggestions on the right approach here.

Happy to submit a PR if this direction looks good.

[nicklockwood]

I'm not convinced that wrapping if expression bodies is not desirable. The main reason for the feature is to make it easier to place breakpoints on the branches, which still seems valid for expressions.

The main reason it looks bad in the examples you've shown is that the expressions were already inlined within another closure, and the wrapped if looks a bit silly being placed on the same line as the opening { if it's then wrapped.

I wonder if there should be another rule that moves wrapped statements onto their own line?

That said, I do think it would make sense to add an option not to wrap if expression bodies (but maybe not enabled by default).

[KYHyeon]

You make a good point about not distinguishing between if expression and statement. I was actually working on an if-only option when I ran into edge cases, which is why I opened this issue first. I'll work on it separately. Thanks!