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
