<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 20, 2016, at 12:07 PM, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><b class="">Earlier on Swift Evolution:</b></div><div class=""><br class=""></div><div class="">Me: "<i class="">Is there a technical reason that Swift cannot be expanded to allow arbitrary mixes of conditional binding and boolean assertions within a single compound guard statement?</i>"</div><div class=""><br class=""></div><div class="">Joe Groff: "<i class="">No. You already can, we just have the somewhat strange rule that to separate `guard` conditions uses `,` before optional or pattern conditions, but `where` before Boolean conditions.&nbsp;</i><i class="">There's no technical reason we couldn't accept either 'where' or ',' consistently."</i></div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>guard x == 0,</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre">        </span> &nbsp;let y = optional where</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre">        </span> &nbsp;z == 2 {</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</font></div><div class=""><br class=""></div><div class=""><b class="">Pitch:&nbsp;</b></div><div class=""><br class=""></div><div class="">I'd like to update Swift's grammar to interchangeably and consistently accept `where` or `,` to separate guard conditions. This would allow a more consistent approach that supports intermingling conditional binding and boolean assertions. Here's a real-world bit of code I was helping someone with a few evenings ago. It's attempting to navigate through some JSON, using optional conditions with where clauses.</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">guard</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let fileContents = fileContents,</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let jsonDict = try NSJSONSerialization.JSONObjectWithData(fileContents, options: []) as? NSDictionary,</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let featuresArray = jsonDict["features"] as? NSArray <b class="">where&nbsp;</b></font><b class=""><font face="Menlo" class="">featuresArray.count &gt; 0,</font></b></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let featuresDict = featuresArray[0] as? NSDictionary,</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let coordinatesArray = featuresDict["geometry"] <b class="">where&nbsp;</b></font><b class=""><font face="Menlo" class="">coordinatesArray.count &gt; 0,</font></b></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let coordinateArray = coordinatesArray[0] as? NSArray <b class="">where&nbsp;</b></font><b style="font-family: Menlo;" class="">coordinateArray.count &gt; 3</b></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; else { fatalError("Reason") }</font></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Each `where` test is a separate test. While there <i class="">are</i> semantic ties between the conditional binding and the count tests, there <i class="">doesn't have to be</i>. Under Swift's current rules, &nbsp;you must use the `where` keyword to introduce a Boolean test after a binding or pattern, regardless of whether or not there's an underlying semantic link between the two.</div><div class=""><br class=""></div><div class="">By removing this requirement and allowing interchangeability between `where` and `,`, you're given the option of tying the boolean to the binding/pattern match or introducing a boolean statement with no connection to previous steps. Here's what this example looks like after excluding `where`:</div><div class=""><br class=""></div><div class=""><span style="font-family: Menlo;" class="">guard</span></div><div class=""><div class=""><span style="font-family: Menlo;" class="">&nbsp; &nbsp; let fileContents = fileContents,</span></div><div class=""><span style="font-family: Menlo;" class="">&nbsp; &nbsp; let jsonDict = try NSJSONSerialization.JSONObjectWithData(fileContents, options: []) as? NSDictionary,</span></div><div class=""><span style="font-family: Menlo;" class="">&nbsp; &nbsp; let featuresArray = jsonDict["features"] as? NSArray,</span></div><div class=""><b class=""><font face="Menlo" class="">&nbsp; &nbsp; featuresArray.count &gt; 0,</font></b></div><div class=""><span style="font-family: Menlo;" class="">&nbsp; &nbsp; let featuresDict = featuresArray.firstObject as? NSDictionary,</span></div><div class=""><span style="font-family: Menlo;" class="">&nbsp; &nbsp; let coordinatesArray = featuresDict["geometry"],</span></div><div class=""><b class=""><font face="Menlo" class="">&nbsp; &nbsp; coordinatesArray.count &gt; 0,</font></b></div><div class=""><span style="font-family: Menlo;" class="">&nbsp; &nbsp; let coordinateArray = coordinatesArray.firstObject as? NSArray,</span></div><div class=""><span style="font-family: Menlo;" class="">&nbsp; &nbsp;&nbsp;</span><b style="font-family: Menlo;" class="">coordinateArray.count &gt; 3</b></div><div class=""><span style="font-family: Menlo;" class="">&nbsp; &nbsp; else { fatalError("Reason") }</span></div></div><div class=""><br class=""></div><div class="">The motivation for this approach becomes more compelling when the Boolean tests are disjoint from binding or pattern matches.</div></div></div></blockquote><div><br class=""></div><div>You can already format the code in a pretty similar way although it is slightly awkward because some lines are required to have commas and others must *not* have commas:</div><div><br class=""></div><div>guard<br class="">&nbsp; &nbsp; let fileContents = fileContents,<br class="">&nbsp; &nbsp; let jsonDict = try NSJSONSerialization.JSONObjectWithData(fileContents, options:&nbsp;[]) as? NSDictionary,<br class="">&nbsp; &nbsp; let featuresArray = jsonDict["features"] as? NSArray&nbsp;</div><div>&nbsp; &nbsp; where&nbsp;featuresArray.count &gt;&nbsp;0,<br class="">&nbsp; &nbsp; let featuresDict = featuresArray[0] as? NSDictionary,<br class="">&nbsp; &nbsp; let coordinatesArray = featuresDict["geometry”]&nbsp;</div><div>&nbsp; &nbsp; where&nbsp;coordinatesArray.count &gt;&nbsp;0,<br class="">&nbsp; &nbsp; let coordinateArray = coordinatesArray[0] as? NSArray&nbsp;</div><div>&nbsp; &nbsp; where&nbsp;coordinateArray.count &gt; 3<br class="">&nbsp; &nbsp; else { fatalError("Reason") }<br class=""><br class=""></div><div>I agree that it would be good to allow boolean expressions to be stand alone clauses in order to support formatting like this without the inconsistency with regards to commas. &nbsp;</div><div><br class=""></div><div>I am less certain about allowing simple boolean expressions that are not introduced by the `where` keyword (excepting the first one which is introduced with the `guard` keyword). &nbsp;I think this is a separate question that should receive independent consideration. &nbsp;I think a reasonable argument can be made both ways. &nbsp;</div><div><br class=""></div><div>Also, looking at these examples I can’t help but notice a another case of a comma separated list that would benefit from&nbsp;allowing newline to be used in place of the commas as well.</div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">guard</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; minimumShapeCount &gt; 4,</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let shapes = decompose(map, minimum: minimumShapeCount),</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; availableArea &gt; minimumArea,</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let map = placeShapes(shapes, availableArea) else {</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; &nbsp; &nbsp; fatalError()</font></div><div class=""><font face="Menlo" class="">}</font></div></div><div class=""><br class=""></div><div class="">would be allowed compared to current Swift which mandates where between the second and third tests:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">&nbsp; &nbsp; let shapes = decompose(map, minimum: minimumShapeCount) where&nbsp;</font><span style="font-family: Menlo;" class="">availableArea &gt; minimumArea,</span></div></div><div class=""><br class=""></div><div class="">In my vision, Swift would continue to allow where clauses and expand to allow disjoint Boolean entries.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">-- E&nbsp;</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>