[Proposal][Discussion] Modular Swift


(Joanna Carter) #1

It's part of what has become Swift style and I'm quite happy about it. Indent on case and on case content is too much indenting :slight_smile:

I would rather that we use the (not-entirely-pleasant-to-me) "curly brace without an indent" used for switches+cases.

Is that actually ‚Äúhow we do things in Swift‚ÄĚ? I always thought it was just Xcode being silly‚Ķ

I should probably file a radar about it in either case.

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;
    }

With Objective-C, all I had to do was move the opening curly brace to the next line and Xcode would keep the same indentation :

    switch (value)
    {
      case pattern:
        code
        break;
        
      default:
        break;
    }

Now, in Swift, not only do I not have the ability to group lines of code together with braces (interpreted as a closure), if I move the opening brace to the next line and indent the cases (for clarity) :

    switch value
    {
      case pattern:
        code
      default:
        code
    }

… although the opening brace stays put, as soon as I reformat a block of code that includes the switch, I automatically lose the indentation of my cases!

And, no matter what I do in Xcode preferences, I don't seem to be able to achieve *my* coding standards for Swift.

There are days when I feel like reverting to Objective-C

···

On 3 Mar 2017, at 11:06, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:

On 3 Mar 2017, at 05:52, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

--
Joanna Carter
Carter Consulting


(Robert Widmann) #2

A lot of ‚ÄúSwift Style‚ÄĚ is ‚ÄúLLVM Style‚ÄĚ enforced in little corners of the language (I, too, like to keep my cases indented a bit further). There are formatting tools available to make your Swift look C#-ish if you want :slight_smile:

···

On Mar 5, 2017, at 7:21 AM, Joanna Carter via swift-evolution <swift-evolution@swift.org> wrote:

It's part of what has become Swift style and I'm quite happy about it. Indent on case and on case content is too much indenting :slight_smile:

On 3 Mar 2017, at 11:06, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:

On 3 Mar 2017, at 05:52, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

I would rather that we use the (not-entirely-pleasant-to-me) "curly brace without an indent" used for switches+cases.

Is that actually ‚Äúhow we do things in Swift‚ÄĚ? I always thought it was just Xcode being silly‚Ķ

I should probably file a radar about it in either case.

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;
   }

With Objective-C, all I had to do was move the opening curly brace to the next line and Xcode would keep the same indentation :

   switch (value)
   {
     case pattern:
       code
       break;

     default:
       break;
   }

Now, in Swift, not only do I not have the ability to group lines of code together with braces (interpreted as a closure), if I move the opening brace to the next line and indent the cases (for clarity) :

   switch value
   {
     case pattern:
       code
     default:
       code
   }

… although the opening brace stays put, as soon as I reformat a block of code that includes the switch, I automatically lose the indentation of my cases!

And, no matter what I do in Xcode preferences, I don't seem to be able to achieve *my* coding standards for Swift.

There are days when I feel like reverting to Objective-C

--
Joanna Carter
Carter Consulting

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


(Chris Lattner) #3

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).

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

···

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;
   }