[DRAFT] Regularizing Where Grammar

(Jon Hull) #1

As a mathematician, for-in-where reads exactly like a set declaration :slight_smile:

{ x ∊ ℤ | x is even } - "For all x in ℤ where x is even”

This makes it feel natural to me (familiar == intuitive). I could see where it would feel unfamiliar to non-math-geeks though.

My preference would be to leave it as is, but if the syntax change actually allows more functionality somehow (or if the old syntax was actually causing serious confusion) I could be pulled to the other side. Just please don’t remove where from for-in loops entirely.



Gist: 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

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>

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


for case? pattern in expression where-clause? code-block

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 <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>> 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