I second Xiaodi. The new names are much improved. Land them in 4.1 or as soon as possible. Depreciations in 5 and removal in 6, though stability may not allow removal.
> On Nov 2, 2017, at 9:58 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
