<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"> * What is your evaluation of the proposal?</div><div class="gmail_extra"><br></div><div class="gmail_extra">“It’s complicated”</div><div class="gmail_extra"><br></div><div class="gmail_extra">First, I agree with the prevailing sentiment that the incomplete-range portion ought to be separated and postponed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Second, the proposed renaming of methods brings great consistency. However, I believe that `first(n)` and `last(n)` read more clearly at the point of use than `prefix(n)` and `suffix(n)`.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The best bikeshed labels I can devise for parameters on the latter are `prefix(limit: n)` and `suffix(limit: n)`. That would narrow the gap in readability, though not close it completely.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Moreover, `removingPrefix(limit: n)` and `removingSuffix(limit: n)` are noticeably verboser (and still a bit less clear) than `removingFirst(n)` and `removingLast(n)`.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"><br class="gmail-Apple-interchange-newline"> * Does this proposal fit well with the feel and direction of Swift?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Changing `drop` to `removing` certainly fits the API naming guidelines.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div><div class="gmail_extra"> * Is the problem being addressed significant enough to warrant a change to Swift?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I am not sure. Rather, the drop-becomes-removing part is significant enough, because the problem being solved is “method names don’t match the API guidelines”, but I am not sure about the rest of the proposal.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regarding incomplete ranges, Matlab uses `end` as a placeholder for the end index, so arr(6:end), and a middle number for step size, so arr(6:2:end).</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think that designing a range-with-stride system is worth considering in the future, so we should not haphazardly introduce an incomplete-range system which might unduly constrain the syntax.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Medium.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Nevin</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 25, 2016 at 2:10 AM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello Swift community,<br>
<br>
The review of "SE-0132: Rationalizing Sequence end-operation names" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md</a><br>
<br>
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
<br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
or, if you would like to keep your feedback private, directly to the review manager.<br>
<br>
What goes into a review?<br>
<br>
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:<br>
<br>
* What is your evaluation of the proposal?<br>
* Is the problem being addressed significant enough to warrant a change to Swift?<br>
* Does this proposal fit well with the feel and direction of Swift?<br>
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
More information about the Swift evolution process is available at<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
<br>
Thank you,<br>
<br>
-Chris Lattner<br>
Review Manager<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><br></div></div>