<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>on Date: Fri, 13 Oct 2017 20:21:22 -0700 Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
We already have whitespace sensitive rules to handle this. There is no fundamental implementation difference that I see between separating the elements of lists (which are expressions) and the elements of statements (which can be expressions):<br>
<br>
func foo() -> Int { … }<br>
<br>
func statements() {<br>
foo()<br>
foo()<br>
}<br>
<br>
let list = [<br>
foo()<br>
foo()<br>
]<br></blockquote><div><br></div><div>i was beaten by these optional semicolons...</div><div><br></div><div>override func viewDidLoad() {</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>super.viewDidLoad()</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>return<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>// put it ad-hoc to temporarily circumvent the rest of the code</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span></div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>someView = SomeView(frame: view.bounds)<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>// *</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>view.addSubview(someView)<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>// **</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>...</div><div>}</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span></div><div>so i put that ad-hoc return statement to circumvent the rest of the code temporarily. of course i didn't put a semicolon after "return" as that skill was long lost. to my surprise the app crashed, and nowhere else but in the code that i thought was disabled...</div><div><br></div><div>further investigation showed that in this case compiler was treating the statement after return which happened to have the matching type “Void” as part of return statement.</div><div><br></div><div>should the function return type was, say, Int - that wouldn’t happen. or should the next statement was of a different type - that wouldn’t happen. in this case i was just “lucky”. here semantic information (matching vs non matching types) is clearly "aiding" syntax parsing and sometimes it leads to a surprising results.</div><div><br></div><div>there was a warning on the * line:</div><div>“warning: expression following 'return' is treated as an argument of the 'return’”</div><div><br></div><div>and another warning on the ** line:</div><div>“warning: code after 'return' will never be executed”</div><div><br></div><div>as i was prepared to get the warning about the code being unused in the first place, i didn’t pay too much attention to the exact wording of that warning... and was beaten by it.</div><div><br></div><div>Mike</div><div><br></div></div></div></div>