<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Maybe something like this?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><div id="AppleMailSignature">let calendar = Calendar.current()</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">for date in dates where calendar.isDateInToday(date) {</div><div id="AppleMailSignature"> //process date only in today</div><div id="AppleMailSignature">}</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">VS.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">for date in dates {</div><div id="AppleMailSignature"> guard calendar.isDateInToday(date) else { continue }</div><div id="AppleMailSignature"> </div><div id="AppleMailSignature">}</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">The where keeps the body of the for loop uncluttered so it can focus *just* on what's important: processing dates that are only in a certain day.</span></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Also, let's pretend someone comes along later and decides to add some code to this loop:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">for date in dates {</span></div><div id="AppleMailSignature"> /** Anything here is using an untested date **/</div><div id="AppleMailSignature"> /** Some programmer comes along later and adds unrelated </div><div id="AppleMailSignature"> * date handling code...or mistakenly adds code here **/</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"> guard calendar.isDateInToday(date) else { continue }</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">}</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">The where tells that this loop was intended to only deal with certain dates and enforces it. Guard only guards against it if code is added after it.</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature">With the where clause it is:</div><div id="AppleMailSignature">- self-documenting</div><div id="AppleMailSignature">- must be changed if you want a different behavior, preventing unintended mistakes later</div></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I don't want to say this is a "more" challenging example of filtering, but I do think it can show its expressiveness.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Brandon</div><br>Sent from my iPad</div><div><br>On Jun 23, 2016, at 10:14 PM, Erica Sadun 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"><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 7:34 PM, William Shipley 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=""><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="">I’m against removing “where" from “for/in”. I use it in my code and I think it aids readability quite a bit. In the example:<div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 16px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class=""><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; padding: 0px; margin: 0px; background-color: transparent; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; border: 0px; display: inline; overflow: visible; line-height: inherit; word-wrap: normal;" class="">for x in theArray where x % 2 == 1 { print (x) }
</code></pre></div></div></div></blockquote><div>I have used odd-even examples a lot when presenting this concept, and inevitably the response</div><div>is "Whoa, that's cool". What I'm missing are more challenging real-world use-cases to justify </div><div>the construct, and an exploration of why the challenging cases would not need debugger </div><div>support at that point.</div><div><br class=""></div><div>My concern (and I am happy to be corrected) is that any code that becomes slightly more </div><div>complex loses the beauty and readability and hinders debugging at the same time.</div><div><br class=""></div><div>-- E</div><div><br class=""></div></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>