[swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

[Nevin Brackett-Rozinsky]

        * What is your evaluation of the proposal?

“It’s complicated”

First, I agree with the prevailing sentiment that the incomplete-range
portion ought to be separated and postponed.

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)`.

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.

Moreover, `removingPrefix(limit: n)` and `removingSuffix(limit: n)` are
noticeably verboser (and still a bit less clear) than `removingFirst(n)`
and `removingLast(n)`.


        * Does this proposal fit well with the feel and direction of Swift?

Changing `drop` to `removing` certainly fits the API naming guidelines.


        * Is the problem being addressed significant enough to warrant a
change to Swift?

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.


        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

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

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.


        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Medium.


Nevin


On Mon, Jul 25, 2016 at 2:10 AM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> Hello Swift community,
>
> 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:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160726/e7b18b8d/attachment.html>