> On Jun 24, 2016, at 5:33 PM, Kevin Ballard <[email protected]> wrote: > > On Fri, Jun 24, 2016, at 11:03 AM, Erica Sadun via swift-evolution wrote: >> >>> On Jun 24, 2016, at 11:26 AM, Karl Wagner via swift-evolution >>> <[email protected]> wrote: >>> >>> -1 >>> >>> I've followed this discussion since the beginning, and I feel the usage is >>> clear given that for...in is a *data-driven* loop >>> >>> I wouldn't mind renaming to "if" if there is some confusion, but I think we >>> use "where" consistently in the language (and Dave Abrahams proposal for >>> closure argument names takes this further), so could be argued that it's >>> already clear. >>> >>> Perhaps we should use "where" consistently for data-filtering operations, >>> and possibly rename the generic constraint specifier. If we wanted to be >>> really rigorously consistent. >>> >>> Karl >> >> I'd much rather keep `where` for protocol constraints and rename >> data-filtering in for-in if kept. My suggestions in the proposal are "if", >> "unless", "until", and "while". > > None of these keywords make sense as a replacement. > > if - This only makes sense if it's a condition that's checked before the loop > starts and causes the entire loop to be skipped. > unless - This has the same problem as if, though it inverts the boolean > condition. > until - This keyword implies that iteration stops when the condition fails, > which is a change in behavior from the where clause (and IMO less useful than > the current where behavior). > while - Same as until, though it inverts the boolean condition. > > I really think we should just keep the where here. I don't think there's any > problem using it both here and in protocol constraints. It means basically > the same thing in both cases, that the thing being modified applies to all > cases (e.g. all types, or all elements of the sequence) where the condition > holds true.
As detailed in the proposal, the keywords cover the space of continue false, continue true, break true, break false. -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
