> On Jun 23, 2016, at 7:42 AM, Ryan Lovelett via swift-evolution > <[email protected]> wrote: >> Is the problem being addressed significant enough to warrant a change to >> Swift? > > No. In fact, I think that even the proposal itself says as much. The > proposal indicates it means to deprecate an available coding style. It > seems to me, as much as is practicable, style changes should be enforced > by something other than the Swift compiler. >
I in no way intended the proposal to "say as much". As syntactic sugar, the filtering syntax is rarely used in published deployed code, hard to discover (although I like others have taught it to promote its visibility), elevates one style (continue if false) above others (continue if false, break if true, break if false), which are not expressible using similar shorthand, introduces a fluent style that discourages design comments at the point of use, can be difficult to breakpoint during debugging. I think these are significant issues. The recommended alternative (using a separate guard) addresses all these points: better commenting, better breakpointing and debugging, and fully covers the domain of filtering and early exiting. If chaining is desired, using filter and prefix(while:) address all conditions, allow better commenting, etc, and are more self-documenting. > On Jun 23, 2016, at 9:07 AM, Tony Allevato via swift-evolution > <[email protected]> wrote: > The fact that some users may be confused by this terminology is not a reason > to remove it from the language. Some users will be confused by many concepts > in programming languages. If that means this is considered an "advanced" > feature, so be it. We should be able to have a language that has both basic > features and advanced features, and when a new developer comes across a > feature they don't understand, they learn it, and then they know it. This is > not an insurmountable problem. For the advanced user, filter and prefix are more customizable and provide greater coverage of cases involving fine control over sequences. > On Jun 23, 2016, at 3:02 AM, Jonathan Hull via swift-evolution > <[email protected]> wrote: > I just taught this to a class of newbies last week and exactly zero of them > had trouble with it. I told my TA that we were debating removing it, and he > was horrified. “It is one of the best features of Swift!” he said. I agree. > It is one of the things which gives Swift character and makes it fun. I have also taught this construct, which is always a counterpoint to discoverability issues. If you step back and ask: "If this feature were not in the language already, would it be added?", we would have to discuss why "positive filtering" should be prioritized as it is and if we include it, what syntax would least confuse users encountering it for the first time. Surrounded as I am by learner-developers, I recognize that this is a real stumbling block -- no matter how ubiquitous it is in SQL, for example -- and have provided examples of both new and experienced developers being confused. For any feature to be included, it should provide measurable benefits, fix a real problem, be named well, be discoverable, and provide non-trivial utility. I think "where", while convenient for a very narrow case of use, fails these tests. -- Erica
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
