On Thu, Nov 2, 2017 at 7:26 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@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! >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
