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

[Nicholas Maccharoli]

+1 here, this irked me for a while as well.

On Mon, Nov 6, 2017 at 10:05 AM, Rudolf Adamkovič via swift-evolution <
swift-evolution at swift.org> wrote:

> Huge +1. Every time I work with collections, I read the type signatures to
> be 100% on whether a method will mutate in place or not. I don’t trust the
> names as they’re not consistent.
>
> R+
>
> Sent from my iPhone
>
> On 3 Nov 2017, at 02:58, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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/swif
>> t-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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20171107/8c707c77/attachment.html>