Can you include an example? I find it hard to visualize for case? pattern 
where-clause? in expression code-block


Thanks,
Brandon

> On Jun 9, 2016, at 3:05 PM, Erica Sadun via swift-evolution 
> <[email protected]> wrote:
> 
> Gist: https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57 
> <https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57>
> 
> Regularizing Where grammar
> 
> Proposal: TBD
> Author: Brent Royal-Gordon <https://github.com/brentdax>, Erica Sadun 
> <http://github.com/erica>
> Status: TBD
> Review manager: TBD
>  
> <https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57#introduction>Introduction
> 
> This proposal fixes an inconsistency for where clause grammar in Swift 
> language for-in loops.
> 
> Swift Evolution Discussion: Add a while clause to for loops 
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/19772/focus=20143>
>  
> <https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57#motivation>Motivation
> 
> Unlike in switch statements and do loops, a for-in loop's where-clause is 
> separated from the pattern it modifies.
> 
> for case? pattern in expression where-clause? code-block
> 
> case-item-list → pattern where-clause? | pattern where-clause? , 
> case-item-list
> 
> catch pattern? where-clause? code-block
> This separation makes the clause harder to associate with the pattern, can 
> confuse users as to whether it modifies the expression or the pattern, and 
> represents an inconsistency in Swift's grammar. This proposal regularizes the 
> grammar to match other uses.
> 
> Note where clauses in case conditions and optional bindings have been removed 
> in SE-0099 
> <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>.
> 
>  
> <https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57#detailed-design>Detailed
>  Design
> 
> Current:
> 
> for case? pattern in expression where-clause? code-block
> Proposed:
> 
> for case? pattern where-clause? in expression code-block
>  
> <https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57#impact-on-existing-code>Impact
>  on Existing Code
> 
> Migration should be easily addressed with a simple fix-it.
> 
>  
> <https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57#alternatives-considered>Alternatives
>  Considered
> 
> Not accepting this proposal
> 
> 
>> On Jun 8, 2016, at 9:23 PM, Brent Royal-Gordon via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>>> This reads to me as “repeat the following block until this fails to be 
>>> true”, the conditional binding in this case fails to be true if 
>>> someCondition(value) isn’t true, so the loop ends. I think the key thing 
>>> here is that the where clause is for the conditional binding and not the 
>>> loop itself, so in this respect it behaves exactly like an if or guard 
>>> statement. Meanwhile:
>>> 
>>>     for eachValue in theValues where someCondition(eachValue) { … }
>>> 
>>> Reads as “for everything in theValues do the following if 
>>> someCondition(eachValue) is also true”, in other words this loop always 
>>> tries to visit every element of the sequence (a while loop has no implicit 
>>> awareness of the sequence, it’s really just an if statement that runs over 
>>> and over). In this case the where clause is part of the loop itself. There 
>>> may be an argument that where should be renamed on for loops to better 
>>> distinguish this, but once you consider that there’s no pattern or 
>>> conditional binding here I think it makes a reasonable amount of sense.
>> 
>> The original sin here was in connecting the `where` clause to the for loop's 
>> sequence expression, rather than its pattern. If `where` were positioned 
>> right after the loop variable:
>> 
>>      for eachValue where someCondition(eachValue) in theValues { … }
>> 
>> It would be much clearer that `where` constrains the values seen by the loop 
>> body.
>> 
>> I'm not sure why the `where` clause was placed where it is. I suspect it has 
>> something to do with the `where` clause potentially being more complex than 
>> the sequence expression, but I was not in the room where it happened, so 
>> that's idle speculation.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> 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