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
> <[email protected]> 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
>> <[email protected] <mailto:[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
>>> <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
>
> _______________________________________________
> 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
