<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I am deeply saddened that a little part of character is lost in swift with the removal of where (imo). But I can be happy that ; is not being used I guess. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">My question: what is/was the rationale for adding <b>where</b> to swift 2? We seem to just be removing it everywhere now (or at least the proposals will be incoming)</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Brandon <br><br>Sent from my iPad</div><div><br>On Jun 8, 2016, at 9:47 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">The review of SE-0099 "Restructuring Condition Clauses" ran from January 13...18, 2016. The proposal has been <b class="">accepted with revision </b>for Swift 3. There was near unanimous agreement that the Swift 2 grammar was inconsistent and ambiguous and should be changed; most of the disagreement centered on how. Many alternatives were discussed, including the following:<div class=""><br class=""></div><div class="">- The proposal as written suggests using ';' or newline as a separator. To many people, this looked heavy, and it's also inconsistent with the rest of the language, which never otherwise used semicolon as an intra-statement separator (except in the defunct for;; loop).</div><div class="">- Introducing a keyword separator, such as using 'where' everywhere or introducing a new 'and' keyword, is also bulky and either reads poorly or requires stealing new keywords.</div><div class="">- Some commenters suggested using '&&' for consistency with simple boolean conditions. This isn't workable due to precedence issues.</div><div class="">- The ambiguities arise from the fact that there are comma-separated lists within comma-separated lists—within the list of conditions, each 'case' or 'let' condition can have multiple declarations. If we eliminated this feature, so that every 'case' or 'let' condition had to start with 'case' or 'let', the ambiguity is resolved, and comma can remain the condition separator. This does break consistency with non-conditional 'let' declarations and case clauses in 'switch' but is otherwise workable.</div><div class=""><br class=""></div><div class="">Of these alternatives, the core team found the last one to be the best choice. 'case' and 'let' conditions should each specify a single declaration, comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer. Some code becomes more verbose, but in common formatting patterns, it aligns more nicely, as in:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>guard</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> let x = foo(),</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> let y = bar(),</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> let z = bas(),</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> x == y || y == z else {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class="">and though it breaks commonality between 'let' conditions and 'let' declarations, it's more important to preserve higher-level consistency throughout the language in how components of expressions and statements are separated. Thanks everyone for the discussion, and thanks Erica and Chris for the proposal! Since, aside from the approved syntax, the fundamental thrust of the proposal remains the same, Chris has volunteered to revise it to be in line with the approved decision.</div><div class=""><br class=""></div><div class="">-Joe</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>