-1 for the reasons already brought up.
I would also point out that half the biasing argument is extremely
questionable: yes, for-in-where is “biased” in favor of “visit-if” and not
"visit-unless”, but this form of “bias” is inevitable unless you start
multiplying keywords (to have one for each “polarity”).
Note that, e.g., `guard` is also biased in a particular direction — we have
`guard $conditionThatMustBeTrue` but not `unless
$conditionThatShouldNotBeFalse` — and although this choice *does* make sense
(due to let-binding being a success-case), it *is* otherwise backwards from
traditional guard clauses (which were usually `if $exitCondition { $exit }`,
which is the opposite polarity from how `guard` works).
So unless you want to have 2 of every control-flow keyword, whenever you have
just one of each you just have to learn the “polarity" of each…this seems
inevitable. Also note that even if you *did* go for 2-of-each, picking names
that are sufficiently self-evident is harder than it looks, so in practice
you’d almost certainly still have to wind up learning at least one of them, if
not both.
Additionally, I would point `for-in-where` has some unique aspects that would
complicate taking the “remove today to improve tomorrow” approach (as has been
done with some other features like splatting).
Specifically, using for-in-where is a stylistic decision, and although
translating its uses *to* `guard-continue` form can be done mechanically,
translating `guard-continue` *back* to the (successor of) `for-in-where` in a
stylistically-appropriate way seems much harder to mechanize…so if it was
dropped for later, improved reinstatement, the temporary dropping might result
in losing a lot of the original human stylistic choice, which IMHO is useful
evidence of the original human intent.
> On Jun 22, 2016, at 11:12 PM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
> Hello Swift community,
>
> The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now
> and runs through June 29. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review
> manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift. When
> writing your review, here are some questions you might want to answer in your
> review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
> _______________________________________________
> 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
