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

[Step Christopher via swift-evolution]

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

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

[Nicholas Maccharoli via swift-evolution]

+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@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@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 > 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@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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rudolf Adamkovič via swift-evolution]

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

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

[Xiaodi Wu via swift-evolution]

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  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] Revisiting SE-0132 Rationalizing Sequence end-operation names

[Brent Royal-Gordon via swift-evolution]

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

And when should we deprecate the old ones?

1. Swift 4.1
2. Swift 4.n
3. Swift 5
4. Swift 6
5. Never

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.

The original proposal, which lists all affected methods and explains the logic 
behind them, is available at 
.
 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!

-- 
Brent Royal-Gordon  
Architechies
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution