[swift-evolution] Revisiting SE-0132 Rationalizing Sequence end-operation names

[Xiaodi Wu]

On Thu, Nov 2, 2017 at 7:26 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> During the Swift 3 cycle, I proposed SE-0132, "Rationalizing Sequence
> end-operation names". It was rejected because it needed revision and there
> was no time to do so. Since then, part of the proposal—partial ranges and
> the `RangeExpression` slicing protocol—has been adopted in SE-0172,
> "One-sided Ranges". I''d like to reopen discussion of the rest of the
> proposal.
>
> To refresh your memory, SE-0132 proposed systematically renaming a number
> of `Sequence` and `Collection` methods which operate on the beginning and
> end of a sequence. Many of these methods have names borrowed directly from
> functional programming; they use terminology in conflicting ways and don't
> follow our conventions for non-mutating method names. For example, consider
> the inconsistent and API Guideline-violating names of a few members which
> operate on the beginning of a sequence or collection:
>
>         first                   dropFirst()
>  removeFirst()
>         prefix(_:)              dropFirst(_:)
>  removeFirst(_:)
>         prefix(while:)  drop(while:)                    —
>
> These members could be renamed to form consistent "families" where a given
> term always meant the same thing:
>
>         first                   removingFirst()         removeFirst()
>         prefix(_:)              removingPrefix(_:)
> removePrefix(_:)
>         prefix(while:)  removingPrefix(while:)  —
>
> The main question in my mind about this plan is source stability. Back
> during Swift 3, we broke compatibility willy-nilly, but today we're being a
> little more circumspect. I believe these names meet the criteria of being
> actively harmful—they are difficult to discover, so developers don't use
> these members even when they should, and many of them sound like mutating
> methods or are unclear about their purpose—but that still doesn't tell us
> how we should treat the old names.
>
> Basically, when should we introduce the new names?
>
>         1. Swift 4.1 (or whatever pre-Swift 5 version the proposal ends up
> landing in)
>         2. Swift 4.n (the version of Swift 5's compatibility mode for
> Swift 4)
>         3. Swift 5
>

(All of the following IMHO:)

Swift 4.1 or whatever is closest. The new names are very clear, and their
introduction doesn't impair backwards compatibility.


> And when should we deprecate the old ones?
>
>         1. Swift 4.1
>         2. Swift 4.n
>         3. Swift 5
>         4. Swift 6
>         5. Never
>

Deprecation warnings: Swift 5. Code continues to compile, and fix-its and a
migrator can get rid of the warning.
Removal of deprecated API: Swift 6; ABI stability may require these symbols
to continue to exist though.

I'm also open to discussion about whether this should be done at all,
> whether any additional methods should be included (or included methods
> should be left alone), whether the now-obsolete `prefix(from:)`
> `prefix(upTo:)`, and `prefix(through:)` methods should be left alone,
> deprecated, or removed, and whether this should be done in this proposal or
> a different one.
>

Could deprecate in Swift 5--don't feel strongly about this one. Definitely
a separate proposal.


> The original proposal, which lists all affected methods and explains the
> logic behind them, is available at <https://github.com/apple/
> swift-evolution/blob/master/proposals/0132-sequence-end-ops.md>. Keep in
> mind that the parts about ranges have already been incorporated into Swift
> in a revised form, so you can ignore them.
>
> I'll get cracking on an implementation once we figure out what I should
> implement.
>
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171102/d1e00ab3/attachment.html>