[swift-evolution] class indent in swift, history?

Adrian Zubarev adrian.zubarev at devandartist.com
Thu Mar 9 00:14:36 CST 2017


Wow the former looks very odd to me. Sure, there are these edge cases across the language which are inconsistent. I myself have filed a bug to always add a trailing space after an operator in operator function for readability and to allow ligatures to render correctly in cases like func == <… compared to func ==<… (but the idea was to add always a space after the operator in functions, even for func == (…). This would add another inconsistency if we’re speaking precisely about function declarations, but I think it’s a valuable tradeoff, especially if you consider that operator functions have it’s own special rule when it comes to the function labels.

I must disagree about braces. To me everything which is multi-lined and inside braces *should* be indented even if the inner part is *part of* the outer statement itself, because that behavior is consistent across the whole language (if we’re not speaking about comment styles).

You can easily imagine a switch statement without braces with some kind of end or endswitch to indicate the end of the statement. Such a switch statement would clearly not need any indent for it’s cases, however I believe most of us felt odd learning Swift and realizing our switch cases are not indented. Don’t get me wrong here, I myself hardly learned to life with that behavior. ;) However sometimes, when I want to write small cases in one line the switch statement looks very odd with its closing brace.

// without braces
switch ab

case .a:  
   print("a")
    
case .b:  
   print("b")
    
endswitch

// VS. our switch statement
// and aligned results (not necessarily needed)
switch ab {
case .a: print("a")
case .b: print("b")
}

// Without the alignment it doesn't feel that odd anymore
switch ab {
case .a:  
   print("a")
case .b:  
   print("b")
}

// But the aligned version cries for indent here
switch ab {
   case .a: print("a")
   case .b: print("b")
}


-- 
Adrian Zubarev
Sent with Airmail

Am 9. März 2017 um 06:25:21, Chris Lattner (clattner at nondot.org) schrieb:


On Mar 8, 2017, at 12:35 AM, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:

The latter slightly confused me for a second and I had to double check. You’re saying that cases are not indented “because” they are part of the switch statement, but observers like willSet and didSet are indented even if they are part of the property they are defined on. What’s the point I’m missing in this argument? (I’m precisely talking about the comparison between cases and observers, not about the indent elsewhere.)

I was confused by an apparent bug in SourceKit.  It looks like top level properties are indented like this:

var zzd : Int = 12 {
didSet {
  print(42)
}
}

But that didSet/willSet are indented when inside of a class:

  var zzd : Int = 12 {
    didSet {
      print(42)
    }
  }

This should clearly be consistent, and the second is the right way to do it, but this behavior invalidates my argument.  The new argument I’d make is that things with braces should definitely be indented :-).  I retain the argument that cases are “part of” the switch statement itself.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170309/1868e5bb/attachment.html>


More information about the swift-evolution mailing list