+1 -Thorsten
> Am 10.06.2016 um 14:49 schrieb Vladimir.S via swift-evolution > <[email protected]>: > > +1 to Haravikk's opinion, my thoughts exactly the same. > >> On 10.06.2016 15:18, Haravikk via swift-evolution wrote: >> >>> On 10 Jun 2016, at 07:25, Xiaodi Wu via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> * Swift is explicitly a C-family language. In most or all other C-family >>> languages, for loop statements allow specification of conditions for >>> exiting the loop but not for filtering. Therefore, Swift's use of `where` >>> is unprecedented and needs to be learned anew by every user of Swift. >> >> Swift may have some similarities with C, but the last thing anyone should >> want is for it to be bound to C as a language. Besides, the purpose of a >> for in loop is to iterate over elements in a sequence, so filtering is very >> much a useful thing to do so it’s hardly unprecedented, and it’s also a >> fairly common thing to want to do. >> >>> * The word "where" does not consistently imply `break` or `continue`. In >>> current Swift, `where` implies `break` in the context of a `while` loop >>> and `continue` in the context of a `for` loop. Some users intuitively >>> guess the correct meaning in each context, while others guess the wrong >>> meaning. Therefore, the only way to learn for sure what `where` means in >>> any context is to read the rulebook. That, by definition, means that this >>> is unintuitive. >> >> This is an argument for renaming the where keyword on for loops to be more >> clear, or to somehow integrate continue/break to be more explicit about >> what the developer intends for it to do. >> >>> * There are other ways to break from a loop or continue to the next >>> iteration without performance penalty. Nearly all of these serve more >>> general purposes than a `where` clause. >> >> This isn’t really an argument against the where clause; the where clause is >> useful for common, simple cases, so it’s not surprising if more >> complex/unusual cases can’t (or can’t easily) be handled by it. This is for >> the simple cases where this isn’t an issue. >> >>> Some of these (such as `if` or `guard`) would already be familiar to a >>> new user before they encounter loops, assuming a typical order for >>> learning a programming language. Many of these (such as filtering methods >>> on collections, or simply `if`) would be familiar to a user of another >>> C-family language. Therefore, the `where` clause provides no independent >>> utility, is not more discoverable than its alternatives, and is not >>> required for progressive disclosure of an important facility to a learner >>> (i.e. a simplified syntax for those who may not be ready for the advanced >>> concepts needed to use a more fully-featured alternative). >> >> Simplification isn’t just for the new users; all you need to know with >> where is that it’s a shorthand for guard X else { continue }, for many >> people this is intuitive enough, but if there are enough for whom it isn’t >> then again that’s an argument to tweak it to be more clear about what it >> does, rather than remove it entirely. >> >> The independent utility that it offers is being able to avoid if/guard >> boilerplate at the start of your loop, but instead putting it on the same >> line; in simple cases this can be nice and neat. >> >>> it has been used incorrectly by at least some users. >> >> Every feature in every language "has been used incorrectly by at least some >> users", should we just drop all programming languages? It’s not as if users >> can’t make mistakes while using an inline if/guard condition. Again, this >> an argument that the meaning isn’t implicit enough, which is just as well >> served by tweaking the syntax than removing it. >> >> >> _______________________________________________ >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
