[swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

[Tony Arnold]

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 at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Jun 23, 2016, at 7:14 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Jun 23, 2016, at 7:34 PM, William Shipley via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/ <http://thecocoabots.com/>

ABN: 14831833541

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/d9c551f0/attachment.html>