I believe this is for case conditionals in for loops only. There is another proposal to remove where from for loops I believe.
I am curious, is there any conflict with the reasoning to move where here compared to the accepted SE-0081 "Move where clause to end of declaration" https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000161.html We moved the where clause to before the body in one case (SE-0081) and now we are trying to move the where clause from before the body to right next to the variable. In SE-0081: "With the proposed change, where clauses do not impede the main declaration and are also more easily formattable" I know these are different uses but it is beginning to hurt my head where all the where clauses are suppose to go in different contexts Brandon Sent from my iPad > On Jun 9, 2016, at 3:57 PM, Haravikk <swift-evolut...@haravikk.me> wrote: > > I think the idea here is for a change from the first to the second of: > > for eachValue in theValues where eachValue.isOdd { … } > for eachValue where eachValue.isOdd in theValues { … } > > I’m kind of split on this for a few reasons. The first is that it doesn’t > ready quite as well plain like this, however I find it looks a bit better > like: > > for (eachValue where eachValue.isOdd) in theValues { … } > > Just to clarify that what we’re looking for in theValues is “eachValue where > eachValue.isOdd”, though I could probably learn to read it like this without > parenthesis. That said, parenthesis lines up nicely with assignment of tuples > like: > > for (eachKey, eachValue where eachValue > 5) in theKeyValuePairs { … } > > But I’m not as sure how to adapt it to the pattern matching variation: > > for (case .Some(let value) where value > 5) in theValues { … } > > It may be harder to declare with parenthesis support like this, I’m not sure. > I think whether or not they’re required in order to declare the where clause > it may be worth considering allowing parenthesis for slightly more complex > cases where it will help to visually group these parts. > > > I’m actually curious whether moving the where clause closer could be a good > (probably future) opportunity to borrow from the closure shorthand: > > for (eachKey, eachValue where $1 > 5) in theKeyValuePairs { … } > > i.e- we allow the same shorthand variable names to avoid having to reuse > eachKey/eachValue in the condition. Not something that needs to be added to > the proposal now, but something it could make possible which may not be as > good an idea with the current positioning, so is worth considering. I raise > this especially because it would likely work best with support for > parenthesis to make it completely clear what the shorthand belongs to, it’s > also the kind of possible improvement that would interest me more vs just > keeping it as-is. > > > Given that today’s been a bit of a whirlwind for the where clause I’m not > sure where to fall on this yet. I’m definitely more in favour of this > compared to removing the where clause entirely, but I still quite like it as > it is now. Just wanted to lend some thoughts for the time being. > >> On 9 Jun 2016, at 20:25, Brandon Knope via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> 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 >>> <swift-evolution@swift.org> wrote: >>> >>> Gist: https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57 >>> >>> Regularizing Where grammar >>> Proposal: TBD >>> Author: Brent Royal-Gordon, Erica Sadun >>> Status: TBD >>> Review manager: TBD >>> 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 >>> >>> 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. >>> >>> Detailed Design >>> >>> Current: >>> >>> for case? pattern in expression where-clause? code-block >>> Proposed: >>> >>> for case? pattern where-clause? in expression code-block >>> Impact on Existing Code >>> >>> Migration should be easily addressed with a simple fix-it. >>> >>> Alternatives Considered >>> >>> Not accepting this proposal >>> >>> >>>>> On Jun 8, 2016, at 9:23 PM, Brent Royal-Gordon via swift-evolution >>>>> <swift-evolution@swift.org> 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 >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
