On Mar 5, 2017, at 4:21 AM, Joanna Carter via swift-evolution 
<swift-evolution@swift.org> wrote:
> 
> I have to say, I really *hate* "Swift style". It wouldn't be so bad if I 
> could change the indentation rules in Xcode.
> 
> For over 25 years, I have written code with curly braces always on their own 
> line, opening ones aligned with the start of the preceding line.
> 
> As for switch..case statement indenting, the default supplied by code 
> completion is laid ou thus :
> 
>    switch value {
>    case pattern:
>      code
>    default:
>      code
>    }
> 
> Whereas, for Objective-C, code completion gives us :
> 
>    switch (value) {
>      case pattern:
>        code
>        break;
> 
>      default:
>        break;
>    }

I can understand how you might find this unnerving, but it is important to 
understand that Swift and Objective-C/C have different semantics when it comes 
to case labels:  in Swift, a case label *is* a scope, and *is* part of the 
switch statement.  In Objective-C, a case label is just a label, like any other 
goto label: it is not a scope and is not necessarily a direct child of the 
switch statement.

C and Objective-C’s behavior is what leads to obscure but important things like 
Duff’s device (https://en.wikipedia.org/wiki/Duff's_device 
<https://en.wikipedia.org/wiki/Duff's_device>).  

In contrast, Swift fixes the scoping, fallthrough, and other related problems 
all in one fell swoop, and ensures that cases are directly nested under the 
switch (unlike in C, where they can be nested under other statements within the 
switch).  Because the case/default labels are *part of* the switch in Swift, it 
makes sense for them to be indented at the same level.

While I can respect that you aesthetically have a preference for the 
Objective-C way of doing things, the rationale for this behavior change wasn’t 
arbitrary and wasn’t due to "LLVM style".  It is an important reflection of the 
core semantics of the language model.

Finally, conservation of horizontal whitespace is important for comprehension 
of code, particularly w.r.t. readability and maintenance.  This is why 
statements like guard exist: to reduce nesting and indentation, directing the 
attention of someone reading and maintaining code to the important parts.

-Chris


_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to