They would differ in, what at least to me, seems pretty logical ways:
>> while !stopped for unit in workToDo where unit.passesTest(condition) {
>> unit.process() }
Would be:
while !stopped {
for unit in workToDo where unit.passesTest(condition) {
unit.process()
}
}
>> for unit in workToDo while !stopped where unit.passesTest(condition) {
>> unit.process() }
Would be:
for unit in workToDo {
guard !stopped else { break }
If unit.passesTest(condition) { unit.process() }
}
This would likely read even better if "where" was woven into the for:
for unit where unit.passesTest(condition) in workToDo while !stopped {
unit.process() }
Or possibly reformatted to something like:
for unit
where unit.passesTest(condition)
in workToDo
while !stopped
{ unit.process() }
l8r
Sean
Sent from my iPad
> On Jun 8, 2016, at 5:42 PM, Tim Vermeulen <[email protected]> wrote:
>
> I’m not sure I follow, how would the two be different?
>
>> There might be value in entertaining the idea of unifying constructs such
>> that they all allow arbitrary combinations of for/while/where/etc.
>>
>> Such as:
>>
>> while !stopped for unit in workToDo where unit.passesTest(condition) {
>> unit.process() }
>>
>> Which would mean something different than:
>>
>> for unit in workToDo while !stopped where unit.passesTest(condition) {
>> unit.process() }
>>
>> And yes, they are very similar visually but differ subtly in meaning, but
>> the same can be said about different sentences in english that might all
>> share the same words and differ only by their order. It’s not exactly a
>> foreign concept! I don’t know of any languages that are quite so expressive
>> as that might be. Are there advantages to something more outlandish like
>> this? I don’t know. I’m not proposing it directly, just thinking out loud, I
>> guess.
>>
>> l8r
>> Sean
>>
>>
>>> On Jun 8, 2016, at 4:44 PM, Haravikk via
>>> swift-evolution<[email protected]>wrote:
>>>
>>>
>>>> On 8 Jun 2016, at 17:11, Xiaodi Wu<[email protected]>wrote:
>>>>> On Wed, Jun 8, 2016 at 3:38 AM,
>>>>> Haravikk<[email protected]>wrote:
>>>>> Yes this could be handled by an if/guard statement with continue, and
>>>>> while as proposed here could be done with the same plus a break, but
>>>>> these things come up so often that it just makes a lot of sense to get it
>>>>> all neatly onto one line.
>>>>
>>>> As I pointed out above with Tim's example, putting it all on one line is
>>>> absolutely not 'neat'--it reads like spaghetti. That is one major beef I
>>>> have with this proposal: that it *encourages* writing on one line too many
>>>> things that, whether you use `where` or not, are much more clearly written
>>>> on multiple lines. If writing everything on one line is for you the major
>>>> advantage of this proposal, we could agree on everything else and I would
>>>> be very much opposed to this proposal on that basis alone.
>>>
>>> I’m not proposing that every single loop have all of its conditions crushed
>>> onto one line, just like I wasn’t when discussing where on the condition
>>> clause thread. The usefulness of where and the proposed while is in the
>>> common, simple cases, for example:
>>>
>>> for eachValue in theValues while eachValue<100 where eachValue % 2 == 0 { …
>>> }
>>>
>>> The alternatives would be:
>>>
>>> for eachValue in theValues {
>>> guard eachValue<100 else { break }
>>> guard eachValue % 2 == 0 else { continue }
>>> …
>>> }
>>> for eachValue in theValues.prefix(while: { $0<100 }).filter({ $0 % 2 == 0
>>> }) { … } // Could also be on multiple lines
>>>
>>> The former wastes vertical space for what it does IMO; it’s fine if the
>>> conditions were more complicated, but since they’re not where/while is
>>> ideal. The second isn’t terrible, but it’s a pretty noisy way to handle
>>> common loop conditions.
>>>
>>> The use of where/while isn’t about eliminating either of these
>>> alternatives, they’re absolutely useful in cases where their drawbacks
>>> become advantages. For example the inline guards are great when the
>>> conditions are more complex, and necessary if you want to do more than the
>>> simple cases allow. The second form is best when you need more than the two
>>> methods, alternate methods, or you have predicates you can pass in
>>> directly, although personally when I do this I tend to do the chinning on
>>> its own lines outside of the loop, leaving me with a loop of: for eachValue
>>> in theFilteredValues { … } or whatever.
>>>
>>>> Closures are--I'm sure you'd agree--a far more advanced concept than
>>>> loops. Concepts like closing over a variable are very, very hard. Many
>>>> useful things can be written without using closures. Not so many things
>>>> could do without loops. It very much matters that a learner might feel
>>>> that he or she cannot understand everything about a loop with the handwavy
>>>> explanation that it'll "come later”.
>>>
>>> Not my point at all; my point was about the shorthand for closures not
>>> closure as a whole, you can’t learn the closure shorthands without first
>>> learning what a closure is. In exactly the same way where/while are just be
>>> shorthands for inline if/guard, you don’t need to learn about these clauses
>>> to make a functioning loop if you know how to do it with your if/guard
>>> statements. In fact it’s better to learn it in this order as once you know
>>> what each clause is a shorthand form of (if/guard continue or break) then
>>> you know exactly what it does already.
>>>
>>>
>>> Ignoring for a moment that you’re opposed to the where clause in general,
>>> what would your thoughts be on only permitting one of where/while in a for?
>>> i.e- you would be able to do only one of:
>>>
>>> for eachValue in theValues where eachValue % 2 == 0 { … }
>>> for eachValue in theValues while eachValue<100 { … }
>>>
>>> But not have both a where and a while on the same line. This eliminates the
>>> question mark around the order they are applied in, while still giving us
>>> the ability to essentially switch the behaviour of the where from continue
>>> to break. I’m not decided whether I want both in a single statement or if I
>>> just want to be able to choose between them. It also limits how much goes
>>> on one line as you have to use an inline condition to achieve both for a
>>> single loop.
>>> _______________________________________________
>>> 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
