Just to clarify: I was +1-ing real world `where` clauses. I am against this proposal.
So… -1 from me on this proposal (and SE-0099 for what it’s worth). Sorry! -t (Thanks for pointing out the confusion my email may have caused, Goffredo) > On 28 Jun 2016, at 10:39, Tony Arnold <t...@thecocoabots.com> wrote: > > I wasn’t going to be +1 guy, but “+1”: > > I use where pretty heavily across both `if let` and in `for … in` loops. > > I find both really readable when formatted, and I’d be disappointed to see > them go. > > I’m super annoyed that I missed (see “wasn’t paying attention during”) the > review of SE-0099 because I would have loved to see `where` remain usable — > it reads better than a comma and forces an order to things that made a lot of > sense to me. > > thanks, > > > Tony > > > >> On 27 Jun 2016, at 18:15, David Rönnqvist via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> We’ve also got two occurrences in our closed source, production code: >> >> for (predicate, callback) in predicatesAndCallbacks where >> predicate(typedEvent) { >> callback(typedEvent) >> } >> >> and: >> >> for conversation in conversations where conversation.state == .Established { >> } >> >> They’re both quite simple and short, but I find them very readable (and I >> find the first one quite elegant). That said, it wouldn’t be much trouble >> for us to rewrite these using guard statements or any other construct. >> >> - David >> >> >>> On 27 Jun 2016, at 00:47, Russ Bishop via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>> On Jun 23, 2016, at 7:14 PM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>>> On Jun 23, 2016, at 7:34 PM, William Shipley via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> 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: >>>>> >>>>> for x in theArray where x % 2 == 1 { print (x) } >>>> I have used odd-even examples a lot when presenting this concept, and >>>> inevitably the response >>>> is "Whoa, that's cool". What I'm missing are more challenging real-world >>>> use-cases to justify >>>> the construct, and an exploration of why the challenging cases would not >>>> need debugger >>>> support at that point. >>>> >>>> My concern (and I am happy to be corrected) is that any code that becomes >>>> slightly more >>>> complex loses the beauty and readability and hinders debugging at the same >>>> time. >>>> >>>> — E >>> >>> Here are two that are shipping right now. >>> >>> for (key, tile) in self._cache where tile.tintColor != self.tintColor { } >>> >>> for innerArray in actualValue where innerArray.contains(expectedElement) { } >>> >>> Russ >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > ---------- > Tony Arnold > +61 411 268 532 > http://thecocoabots.com/ <http://thecocoabots.com/> > > ABN: 14831833541 > ---------- Tony Arnold +61 411 268 532 http://thecocoabots.com/ <http://thecocoabots.com/> ABN: 14831833541
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
