Line breaks not respected in statement conditions

[AnthonyLatsis]

Before:

switch x {
case let term
where
  term.hasPrefix("screen") ||
  term.hasPrefix("xterm") ||
  term.hasPrefix("vt100") ||
  term.hasPrefix("rxvt") ||
  term.hasSuffix("color"):
  return false
}

if term.hasPrefix("screen") ||
  term.hasPrefix("xterm") ||
  term.hasPrefix("vt100") ||
  term.hasPrefix("rxvt") ||
  term.hasSuffix("color")
{
  return false
}

After:

switch x {
case let term
where
  term.hasPrefix("screen") || term.hasPrefix("xterm") || term.hasPrefix("vt100") || term.hasPrefix("rxvt")
  || term.hasSuffix("color"):
  return false
}

if term.hasPrefix("screen") || term.hasPrefix("xterm") || term.hasPrefix("vt100") || term.hasPrefix("rxvt")
  || term.hasSuffix("color")
{
  return false
}

Interestingly, the formatter doesn’t mind

if term.hasPrefix("screen")
  || term.hasPrefix("xterm")
  || term.hasPrefix("vt100")
  || term.hasPrefix("rxvt")
  || term.hasSuffix("color")
{
  return false
}

I could not file a rule for specifying breaking behavior around operators, so presumably it should not matter to the formatter.

[AnthonyLatsis]

Configuration:

{
    "version": 1,
    "lineLength": 120,
    "indentation": {
        "spaces": 2
    },
    "lineBreakBeforeEachArgument": true,
    "indentConditionalCompilationBlocks": false,
    "prioritizeKeepingFunctionOutputTogether": true,
    "respectsExistingLineBreaks": true,
    "rules": {
        "DoNotUseSemicolons": true,
        "AlwaysUseLowerCamelCase": false,
        "AmbiguousTrailingClosureOverload": false,
        "NoBlockComments": false,
        "OrderedImports": true,
        "UseLetInEveryBoundCaseVariable": false,
        "UseSynthesizedInitializer": false,
        "ReturnVoidInsteadOfEmptyTuple": true,
    }
}

[allevato]

respectsExistingLineBreaks is more like respectsExistingLineBreaksInPositionsTheFormatterConsidersValid. In this case, the formatter has a non-configurable rule that line breaks occur before infix operators, except for assignment operators, in which they occur after.

I've thought about having some logic that tries to repair these specific cases by shifting the user-inserted line break to the other side of the operator instead of just discarding it completely, but it's never been a high priority.

[HolmesZhao]

I also have this question, such as:

and another issue is:

before:

after:

[allevato]

Those examples are all consistent with the formatter's correct behavior as it is currently implemented. In both cases, those are standard indented continuation lines.

[HolmesZhao]

Those examples are all consistent with the formatter's correct behavior as it is currently implemented. In both cases, those are standard indented continuation lines.

the first, when I click keyboard Enter, the xcode will show this:

[allevato]

While there's a swift-format menu option in Xcode, Xcode's interactive formatting and swift-format's rules are not always the same; they've evolved independently.

I don't work on Xcode (or at Apple), so I can't speak to whether there are any efforts to make Xcode format more like swift-format by default, and we don't use Xcode's decisions to guide changes to swift-format.