Clearly, if the predicate for prefix is very expensive, it can be evaluated after filtering for evens, or it can be evaluated inside the loop. And that goes to my point: writing things out explicitly will cause you to think about these issues, whereas a `while` clause tends to obscure them.<br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 8, 2016 at 10:40 Vladimir.S <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">IMO `.prefix` is just not the equal alternative for as proposed `while` :<br>
in case of 'while' expression `number < 4_000_000` will be calculated<br>
*only* for those who `number % 2 == 0`. In case of `prefix` - the<br>
expression will be processed for each `number` and only after this filtered<br>
by `number % 2`. Let's assume we need to check for some<br>
veryExpensiveTest(number):<br>
<br>
for number in fibonacci where number % 2 == 0 while<br>
veryExpensiveTest(number) {}<br>
<br>
let numbers = fibonacci.prefix { veryExpensiveTest($0) }<br>
for number in numbers where number % 2 == 0 {}<br>
<br>
So, `while` for `for` loops just can't be always replaced with `prefix`<br>
<br>
On 08.06.2016 2:02, Xiaodi Wu via swift-evolution wrote:<br>
> On Tue, Jun 7, 2016 at 5:11 PM, Tim Vermeulen <<a href="mailto:tvermeulen@me.com" target="_blank">tvermeulen@me.com</a><br>
> <mailto:<a href="mailto:tvermeulen@me.com" target="_blank">tvermeulen@me.com</a>>> wrote:<br>
><br>
> I’ve been thinking about this for a bit now, and I think it would make<br>
> most sense to evaluate these clauses from left to right. However, cases<br>
> where the order matters are very uncommon, and I would rather have the<br>
> power to choose which clause is evaluated first than to have a forced<br>
> default order. Either way I don’t see this as a reason not to allow<br>
> combining the two clauses because IMO it can lead to some very clean<br>
> code. For instance, say we want to loop through all even fibonacci<br>
> numbers below 4 million (see problem #2 from project euler), we could<br>
> do this:<br>
><br>
> `for number in fibonacci where number % 2 == 0 while number < 4_000_000<br>
> { }`<br>
><br>
><br>
> This statement looks like spaghetti to me. I would not at all support<br>
> extending the language to permit it. Do you really think it's more readable<br>
> than going step-by-step?<br>
><br>
> ```<br>
> let numbers = fibonacci.prefix { $0 < 4_000_000 }<br>
> for number in numbers where number % 2 == 0 {<br>
> // ...<br>
> }<br>
> ```<br>
><br>
> or just:<br>
><br>
> ```<br>
> let numbers = fibonacci.prefix { $0 < 4_000_000 }<br>
> let evens = numbers.filter { $0 % 2 == 0 }<br>
> for number in evens {<br>
> // ...<br>
> }<br>
> ```<br>
><br>
><br>
> I could have ordered the two clauses in any way I want. If combining<br>
> the clauses weren’t allowed, I’d have to put (at least) one of them<br>
> inside the block, which would be a (minor) pain.<br>
><br>
> I don’t currently have a very strong opinion about the order of<br>
> evaluation, so I might be convinced otherwise. But combining the two<br>
> clauses is so powerful that I don’t think it’s worth to get rid of just<br>
> because of an edge case.<br>
><br>
> > It may be workable if you can have only one or the other, but mixing and matching them as proposed above would be a world of hurt:<br>
> ><br>
> > ```<br>
> > for foo in bar where condition1 while condition2 { ... }<br>
> > ```<br>
> ><br>
> > If condition1 and condition2 both evaluate to true, then whether you continue or break would depend on the relative order of where and while; for generality, you would want to allow both `for...in...where...while` and `for...in...while...where`, and likely `for...in...while...where...while`, etc. There is nothing in the meaning of those words that would suggest that `while...where` behaves differently from `where...while`, etc. This is why words like "break" and "continue" are IMO far superior.<br>
> ><br>
> ><br>
> > On Tue, Jun 7, 2016 at 2:34 PM, Erica Sadun<<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a><br>
> <mailto:<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>>(mailto:<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a><br>
> <mailto:<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>>)>wrote:<br>
> > ><br>
> > > > On Jun 7, 2016, at 1:16 PM, Tim Vermeulen via swift-evolution<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>(mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>)>wrote:<br>
> > > > > The meaning of the proposed while is not at all a pair for where, since where clauses in while loops would do the same thing as while clauses in for loops. That's crazy.<br>
> > > ><br>
> > > > It sounds crazy, but it’s the nature of the while loop. A where clause in a while loop also has a different result than a where clause in a for loop.<br>
> > ><br>
> > > The where_clause appears in the for in statement<br>
> > ><br>
> > > for_in_statement : 'for' 'case'? pattern 'in' expression where_clause? code_block<br>
> > ><br>
> > > It's syntactic sugar because the expression can be already be limited through functional chaining of some sort or another. At the same time, it's nice and pleasant to have `where` and I'm not itching to throw it out. The same courtesy could be easily extend to `when` (because I don't really want to use the `while` keyword here, but I could easily be convinced otherwise because I don't have a strong stance either way):<br>
> > ><br>
> > > for_in_statement : 'for' 'case'? pattern 'in' expression (where_clause | when_clause)? code_block<br>
> > > when_clause : 'when' expression<br>
> > ><br>
> > > and again it could be nice and pleasant to have, although not necessary. The question comes down to how much does the language benefit by this sugar.<br>
> > ><br>
> > > I'd say that in both cases, combining chaining and statements is<br>
> marginallyless goodthan either using standalone chaining or statements<br>
> without chaining. But as I say this, I know as a fact, I fully intend<br>
> to use `sequence(_:, next:).take(while:)` with for0in statements, so<br>
> I'm starting from a hypocritical vantage point.<br>
> > ><br>
> > > To summarize, I'm more +0.01 than I am -0.01 on this.<br>
> > ><br>
> > > -- E<br>
> > > p.s. Sorry, wux<br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> ><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
</blockquote></div>