I think Jacob said it already: there's no "x in foo()" construct that you could 
add a 'where' to. There's just a 'for' loop; part of the syntax for 'for' loops 
is the keyword 'in' and the keyword 'where'.

Now that doesn't mean we couldn't add this—it's basically a limited/small form 
of list comprehension—but then I personally say -1. 'filter' is good enough for 
me.

Jordan

> On Dec 19, 2015, at 22:10 , Charles Constant via swift-evolution 
> <[email protected]> wrote:
> 
> Hi Jacob,
> 
> I take it that's a -1 ?
> 
> I don't quite understand your example, because y in a "for" loop is an Array. 
> So if I modify your example (I'll rename "y" to "numbers")...
>  
>     for x in numbers where x > 2 { }
> 
> ...my intuition immediately barks "it's a filter!"
> 
>     let valid_numbers = x in numbers where x > 2
> 
> I realize it's good to have a closure-based solution for map/filter/reduce, 
> so fair enough that we let the filter method exist. Maybe if I understood 
> Swift better (is this related to sequences?) this would all make sense... but 
> with what grasp of Swift I do have, it makes the language feel baroque to 
> have this "where" clause that looks like it ought to instantiate an array, 
> but can't. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sat, Dec 19, 2015 at 9:45 PM, Jacob Bandes-Storch <[email protected] 
> <mailto:[email protected]>> wrote:
> It doesn't bother me, because I read it as an additional constraint on the 
> `for` loop rather than an operation being done on the enumerated sequence. 
> That is,
> 
>     for x in y where x > 2 { }
> 
> is fairly consistent with 
> 
>     if let x = y where x > 2 { }
> 
> And you wouldn't expect to be able to do "let x = y where x > 2".
> 
> Jacob Bandes-Storch
> 
> On Sat, Dec 19, 2015 at 8:22 PM, Charles Constant via swift-evolution 
> <[email protected] <mailto:[email protected]>> wrote:
> Thanks Charles ,
> 
> I know it's possible to do the same thing with filter. The syntax I drew 
> attention to would be an alternate way. 
> 
> My only rationale is that, if it works in one place, it ought to work 
> everywhere. The redundancy bothers me too, but since the concept exists, we 
> may as well allow it everywhere. Otherwise, it's still redundant in a "for" 
> loop (maybe performance is better, but that could be optimized?), but also 
> inconsistent because it seems intuitively like it ought to create a subset 
> whereas in reality it is illegal.
> 
> Does it bother anyone else, or am I nitpicking?
> 
> On Sat, Dec 19, 2015 at 7:52 PM, Charles Srstka <[email protected] 
> <mailto:[email protected]>> wrote:
>> On Dec 19, 2015, at 9:43 PM, Charles Constant via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>> I noticed several weeks ago that the following is illegal:
>> 
>>     let new_arr = el in arr where el.is <http://el.is/>_foo // illegal
>> 
>> I assumed it would work because it's consistent with the filtering that 
>> exists in a "for" loop, i.e.:
>> 
>>     for el in arr where el.is <http://el.is/>_foo // legal
>> 
>> Is this "new proposal" material? I thought I would check in case it's 
>> already on the roadmap, or inherently wrong.
> 
> I believe what you want is already possible via the “filter” method.
> 
> Charles
> 
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to