> 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 
<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), 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

Reply via email to