@allevato

This is the intended behavior under the (current) default configuration. The reasoning behind this is:

• Continuation lines that do not begin with closing delimiters are indented at a fixed +2 from the line where their starting line.

• When an open brace would be placed at the end of an indented continuation line, it is moved onto its own line so that the body of the brace-delimited block (which is also indented +2 from the starting line of that brace) are visually distinguishable from the preceding continuation lines.

• Treating continuation line indentation as an invariant, the ability to distinguish the body of the statement from the continuation lines above it was/is felt to be a much higher priority for readability than always keeping the opening brace on the same line.

We can certainly add a configuration option to use keyword-length-based indentation variable for some statements and tie open-brace placement to that, though. I think that makes this request a dupe of SR-12844.

@allevato

> When an open brace would be placed at the end of an indented continuation line, it is moved onto its own line so that the body of the brace-delimited block (which is also indented +2 from the starting line of that brace) are visually distinguishable from the preceding continuation lines.

If the brace-delimited block is indented from the line with the open brace, they would still be visually distinguishable:

if let someCondition = blah(),
  someOtherConditions(),
  yetMoreConditions {
     braceDelimitedBlock()
     thisIsOkayIMO()
}

To me, that looks better than bumping the opening brace to a new line. It would be nice if there were some flag to say that I consider that sufficient.

I'm not personally aware of any indentation style in common use among curly-brace languages (that's not to say one doesn't exist) that does what you describe; bodies of brace delimited blocks are always indented uniformly from the level of the containing syntactic construct, not the level of the line that happened to contain the brace.

Instead, it's much more common to differentiate by having the continuation indent be larger than the block indent:

if let someCondition = blah(),
    someOtherConditions(),
    yetMoreConditions {
  braceDelimitedBlock()
}

Between the two choices, I'd much rather support this one as a configurable option, since it has significant precedent across other similar languages/style guides.

Unfortunately, that would not compose well with SR-12844, which would align the conditions. Indenting from the continuation line would:

if let someCondition = blah(),
   let anotherCondition = blah(),
   yetMoreConditions {
     braceDelimitedBlock()
}

Looks both tidy and unambiguous, IMHO.

To clarify, they wouldn't be intended to compose at all; if we make this configurable, users would choose either the current indentation strategy, the scope-based indentation strategy, or a fixed continuation line indentation strategy.

Your suggested approach suffers from the problem that conditions/bindings with complex expressions that themselves introduce a lot of nesting would potentially introduce a large shift in the indentation of the body:

if let someValue = thingThatReturnsAnOptional(),
   let otherValue = anotherOptionalReturningFunction(),
   let nextValue = someValue.method(
     firstTerm * secondTerm + thirdTerm - otherValue.method(
       aReallyLongArgumentName + anotherReallyLongArgumentName
         * moreReallyLongArgumentNames)) {
           bodyOfTheBlockStartsHere()
}

Whereas the other approaches (the current implementation, or the continuation-indent-is-larger-than-block-indent) cause the body to be pulled back to a reasonable location.

One can argue that if a condition is so complex it should be hoisted into a temporary variable or separate function anyway, and that may work for some basic conditions, but due to the way the scopes and sequencing of conditional bindings work in Swift, trying to pull those out might end up having a negative impact on the readability of the code.

Ultimately, the degree to which we support fine-tuning configurability in swift-format won't be unlimited because every option that gets added potentially interacts with other options, which can lead to a combinatorial explosion in the condition space we have to consider when deciding how to lay out certain nodes, as well as a combinatorial explosion of the tests to ensure that we don't break things for some particular configuration. In this case, I don't think the tidiness/unambiguity is as clear as the alternatives, nor is there much precedent for it.