<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On May 27, 2016, at 4:35 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="">I am not a fan of this syntax. `;` reads very strongly as a statement ender to me,</div></div></blockquote><div><br class=""></div><div>Technically speaking, Swift uses semicolon as a separator, not a line ender. We already use it to separate multiple expressions on the same line, typically when those expressions are side effecting:</div><div><br class=""></div><div> print(“foo”); print(“bar”) // silly example</div><div><br class=""></div><div>The proposal is consistent with this usage.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> and yet at the same time, it's still visually quite close to `,`. My first impression was that the proposal had an embarrassing typo in the very first example.<br class=""></div></div></blockquote><div><br class=""></div><div>Particularly if we end up with Matthew’s proposal to allow omitting the semicolon when it is at the end of the line, I think we’d end up with much nicer looking code in practice. Here are a couple of random example conditions I pulled from AlamoFire (feel free to pick some of your own):</div><div><br class=""></div><div>Now:</div><div><font face="Menlo" class=""> if let<br class=""> path = fileURL.path,<br class=""> fileSize = try NSFileManager.defaultManager().attributesOfItemAtPath(path)[NSFileSize] as? NSNumber</font></div><div><font face="Menlo" class=""> {<br class=""></font> </div><div><br class=""><font face="Menlo" class=""> guard let<br class=""> path = fileURL.path<br class=""> where NSFileManager.defaultManager().fileExistsAtPath(path, isDirectory: &isDirectory) && !isDirectory else<br class=""> {</font></div><div><br class=""><font face="Menlo" class=""> if let path = fileURL.path where NSFileManager.defaultManager().fileExistsAtPath(path) {<br class=""></font><br class=""></div><div><br class=""></div><div>With SE-0099 + Matthew’s extension, this could be written more nicely as:</div><div><br class=""></div><div><div><font face="Menlo" class=""> if let path = fileURL.path<br class=""> let fileSize = try NSFileManager.defaultManager().attributesOfItemAtPath(path)[NSFileSize] as? NSNumber</font></div><div><font face="Menlo" class=""> {</font><br class=""></div><div><br class=""><font face="Menlo" class=""> guard let path = fileURL.path<br class=""> NSFileManager.defaultManager().fileExistsAtPath(path, isDirectory: &isDirectory)</font></div><div><font face="Menlo" class=""> !isDirectory else<br class=""> {</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> if let path = fileURL.path; NSFileManager.defaultManager().fileExistsAtPath(path) {<br class=""></font></div><div class=""><font face="Menlo" class=""><br class=""></font></div></div><div>To be clear, I’m not saying I prefer alamofire’s indentation style :-)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">My suggestion would be to reuse our normal && operator:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>guard<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>x == 0 &&<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>let y = optional &&<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>z == 2<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>else { ... }<br class=""><br class="">This would obviously be a built-in `&&` separate from our existing, infix operator `&&`. </div></div></blockquote><div><br class=""></div><div>Yes, this is technically feasible, but it has the opposite problem from the above: && is very closely associated (in terms of programmer mindspace) with boolean conditionals, and the let/case clauses are *not* boolean conditions.</div><br class=""></div><div>-Chris</div><br class=""></body></html>