<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 class="">I certainly am warm to that myself, although I’m also sympathetic to what Chris wrote about the inconsistency it introduces:</div><div class=""><br class=""></div><div class=""><div class=""> let x = optionalX!, y = optionalY! // Works!</div><div class=""> doStuff(x, y)</div><div class=""><br class=""></div><div class=""> if let x = optionalX, y = optionalY { // Doesn’t work. Confusion!</div><div class=""> doStuff(x, y)</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">Also, eliminating the repeated “let” in a big list of conditional bindings is a common practice:</div><div class=""><br class=""></div><div class=""><div class=""> if let firstName = json["first_name"],</div><div class=""> lastName = json["last_name"],</div><div class=""> street = json["street"],</div><div class=""> state = json["state"],</div><div class=""> zip = json["zip_code"] {</div><div class=""> ... </div><div class=""> }</div></div><div class=""><br class=""></div><div class="">…and some style guides even go out of their way to recommend this over the repeated “let.” Popular feature, so I’d be hesitant to nix it.</div><div class=""><br class=""></div><div class="">P</div><br class=""><div><blockquote type="cite" class=""><div class="">On May 31, 2016, at 5:04 PM, Hooman Mehr <<a href="mailto:hooman@mac.com" class="">hooman@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Exactly what I feel about this. <div class=""><br class=""></div><div class="">I am prepared to go as far as disallowing:<div class=""><br class=""></div><div class="">let x = optionalX, y = optionalY </div><div class=""><br class=""></div><div class="">syntax to free up comma for use instead of semicolon. Then the above becomes:</div><div class=""><br class=""></div><div class="">let x = optionalX, <b class="">let</b> y = optionalY</div><div class=""><br class=""></div><div class="">In this case we will keep the comma at the end of the line as well.</div><div class=""><br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 31, 2016, at 2:25 PM, Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Returning to the list after a brutally busy spring, a demi-review:<br class=""><br class="">I vote…<br class=""><br class="">+1 on addressing this problem,<br class="">+1 on the proposal’s structural approach (list of items which may be either boolean tests or bindings, in any order), and<br class="">+1 on eliminating “where” in the presence of a better approach,<br class=""><br class="">…but am ambivalent about the semicolon. Hereafter follows a slushy reflection on my deepest inner thoughts and feelings about syntax.<br class=""><br class="">The logic behind the semicolon makes perfect sense, but my initial gut reaction agrees with others who say it just isn’t pleasant to read. I spent some time fiddling with places in my code where I’ve used “if … where” and tried the proposed syntax instead. It feels … off.<br class=""><br class="">Commas in the same spots feel better somehow. I spent some time reflecting on why this might be, and I think it’s just that my brain is so strongly trained to parse the semicolon as a statement separator. IOW, my mental hierarchy is this:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>expression<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>comma<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>statement<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>semicolon ←<br class=""><br class="">…(and this is intuitively true for me despite the C-style for loop), but the proposal asks us to read this way instead:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>expression<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>comma<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>semicolon ←<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>statement<br class=""><br class="">In particular, my years of C trained me to spot this mistake:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if(foo < bar);<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> oopsThisAlwaysExecutes();<br class=""><br class="">…and seeing that semicolon on the same line as the “if” in Swift triggers that deeply conditioned alarm bell. Then again, “if let” and “if case” have always felt weirdly wrong to me as well, and I eventually got used to them. I’d probably get used to this proposed syntax as well.<br class=""><br class="">The line breaks look better than semicolons, but suffer a bit from the same “statement boundary” brain retraining problem.<br class=""><br class="">Somebody proposed && (Brent maybe?). I tried it out too. It’s surprisingly pleasant to read, but makes it look like I should be able to arbitrarily embed bindings deep in expressions in ways that would open hideous cans of worms:<br class=""><br class=""> if let foo = bar && barTest(foo) || let foo = baz && bazTest(foo) {<br class=""> // Is foo defined here? What is its type? Yikes!<br class=""> }<br class=""><br class="">Communicating that the top-level separator in a condition clause is not just another boolean operator does seem important.<br class=""><br class="">Bottom line: the proposal addresses a real problem, and the proposed solution is an improvement. If the choice is either current syntax or SE-0099, I vote for SE-0099. I have a nagging feeling there’s a better third choice out there somewhere. If there isn’t, then I’ll take SE-0099.<br class=""><br class="">Cheers,<br class=""><br class="">Paul<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></body></html>