<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>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 <code>willSet</code> and <code>didSet</code> 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.)</p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1488961639302792192" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 8. März 2017 um 07:29:35, Chris Lattner via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Hi Will,<br><br>Good question: the general rationale is that true nesting implies indentation in Swift. Cases are not indented under “switch” because they are part of the switch statement, and, similarly, didSet is part of the property it is defined on. In contrast, nested types really are nested, they aren’t part of the enclosing declaration.<br><br>-Chris<br><br><br>> On Mar 6, 2017, at 10:42 PM, Will Stanton <willstanton1@yahoo.com> wrote:<br>> <br>> Hello Chris and perhaps core team members,<br>> <br>> The comments on tab-levels for `switch` made me want to ask about the considerations that went into class and protocol-level indentation.<br>> <br>> Sorry if my wording isn’t precise, but in Objective-C, functions can (should) be at the same 0-indent level as the class:<br>> @implementation Foo<br>> // No indent!<br>> - (void)doSomething {<br>> }<br>> @end<br>> <br>> However, in Swift, method and nested types are indented by default:<br>> class Foo : Bar {<br>> // Things indented!<br>> enum Types {<br>> }<br>> func doSomething() {<br>> }<br>> }<br>> <br>> <br>> Was the change mostly driven by the desire for protocol+class+struct+enum consistency in ‘increasing’ the scope+indent level? Were there other considerations?<br>> Why didn’t the language evolve into something like this to reduce the use of horizontal whitespace, allowing class functions/types at the root/top level? Like:<br>> @class Foo : Bar<br>> enum Types {<br>> }<br>> func doSomething() {<br>> }<br>> @end<br>> <br>> <br>> Regards,<br>> Will Stanton<br>> <br>>> On Mar 7, 2017, at 12:52 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:<br>>> <br>>> 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.<br>>> <br>>> 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). <br>>> <br>>> 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.<br>>> <br>>> 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.<br>>> <br>>> 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.<br>>> <br>> <br><br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>