On Mon, Jun 13, 2016 at 10:54 AM, Erica Sadun <er...@ericasadun.com> wrote:
> > On Jun 13, 2016, at 9:44 AM, let var go via swift-evolution < > swift-evolution@swift.org> wrote: > > I think we must be reading different discussions. > > What I have seen in this discussion is the following: > > a) The need to filter a for-in loop doesn't arise that often; but, > b) When it does arise, everyone who has chimed in on this thread (except > the two people who are proposing the change) thinks that the "where" clause > is the clearest, most expressive way to do it. > > > As a point of order, may I request you stop singling out "the two people > who are proposing the change" and discuss the merits of the pitch rather > than the people involved in the discussion. Details of the Swift community > code of conduct can be found here: > https://swift.org/community/#code-of-conduct > > As syntactic sugar, the filtering syntax is rarely used, hard to discover, > and elevates one style (continue if false) above others (continue if false, > break if true, break if false > ...and, a surprising number I noted from doing a rough GitHub search (many more than I thought I would see): return if true, return if false, fatalError if true, fatalError if false. > ), which are not expressible using similar shorthand. It introduces a > fluent style that discourages design comments at the point of use and can > be difficult to breakpoint during debugging. 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. > > In response, I'd like to hear why "continue if false" should be > prioritized above the other options and should be retained, or > alternatively why the suite should be completed (as in the original > discussion with "while") in preference to the advantages accrued by guard. > > Thank you, > > -- Erica >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution