[swift-evolution] Revisiting SE-0132 Rationalizing Sequence end-operation names
xiaodi.wu at gmail.com
Thu Nov 2 20:58:25 CDT 2017
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
> 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()
> prefix(_:) dropFirst(_:)
> 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(_:)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution