[Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly


(Douglas Gregor) #1

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md

Hello Swift Community,

The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs Accordingly” ran from March 31...April 5, 2016. The proposal is accepted.

There was much debate, both before and during the review, over the “InPlace” suffix/ “form” prefix, and at this point any answer will be objectionable to some. The core team has opted to accept the proposal as-is, keeping the “form” prefix to describe the mutating counterpart to an operation naturally described by a noun (e.g., “formUnion” for the mutating variant of “union”), for the reasons described in the proposal itself. Thanks all for the spirited discussion!

  - Doug


(Vladimir) #2

Just wanted to go back to
Apply API Guidelines to the Standard Library SE-0006
https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
for a second.

Just found out that this code is working in 3.0(mar 24):
var z1 = [3,2,1]
let z2 = z1.sort() // mutating method!
print(z2) // => ()

so.. is this a final implementation or we are expecting to have a lot of hard-to-find errors in our Swift 3.0 code if code written for previous Swift will be used(private lib/snippet/etc)?

Also, just interesting, are we all expecting libs like RxSwift and ReacriveCocoa will rename their methods accordingly to names changed in Swift 3.0?

···

On 19.04.2016 0:18, Douglas Gregor via swift-evolution wrote:

Proposal
link: https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md

Hello Swift Community,

The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs
Accordingly” ran from March 31...April 5, 2016. The proposal is *accepted*.

There was much debate, both before and during the review, over the
“InPlace” suffix/ “form” prefix, and at this point any answer will be
objectionable to some. The core team has opted to accept the proposal
as-is, keeping the “form” prefix to describe the mutating counterpart to an
operation naturally described by a noun (e.g., “formUnion” for the mutating
variant of “union”), for the reasons described in the proposal itself.
Thanks all for the spirited discussion!

- Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Douglas Gregor) #3

Just wanted to go back to
Apply API Guidelines to the Standard Library SE-0006
https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
for a second.

Just found out that this code is working in 3.0(mar 24):
var z1 = [3,2,1]
let z2 = z1.sort() // mutating method!
print(z2) // => ()

so.. is this a final implementation or we are expecting to have a lot of hard-to-find errors in our Swift 3.0 code if code written for previous Swift will be used(private lib/snippet/etc)?

Also, just interesting, are we all expecting libs like RxSwift and ReacriveCocoa will rename their methods accordingly to names changed in Swift 3.0?

It definitely seems reasonable for us to warn on this kind of example, e.g., placing a Void result of a call to a mutating method in a variable. Can you file a ticket a bugs.swift.org? It would be a great starter bug.

  - Doug

···

On Apr 19, 2016, at 12:41 AM, Vladimir.S <svabox@gmail.com> wrote:

On 19.04.2016 0:18, Douglas Gregor via swift-evolution wrote:

Proposal
link: https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md

Hello Swift Community,

The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs
Accordingly” ran from March 31...April 5, 2016. The proposal is *accepted*.

There was much debate, both before and during the review, over the
“InPlace” suffix/ “form” prefix, and at this point any answer will be
objectionable to some. The core team has opted to accept the proposal
as-is, keeping the “form” prefix to describe the mutating counterpart to an
operation naturally described by a noun (e.g., “formUnion” for the mutating
variant of “union”), for the reasons described in the proposal itself.
Thanks all for the spirited discussion!

- Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Vladimir) #4

Just wanted to go back to
Apply API Guidelines to the Standard Library SE-0006
https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
for a second.

Just found out that this code is working in 3.0(mar 24):
var z1 = [3,2,1]
let z2 = z1.sort() // mutating method!
print(z2) // => ()

so.. is this a final implementation or we are expecting to have a lot of hard-to-find errors in our Swift 3.0 code if code written for previous Swift will be used(private lib/snippet/etc)?

Also, just interesting, are we all expecting libs like RxSwift and ReacriveCocoa will rename their methods accordingly to names changed in Swift 3.0?

It definitely seems reasonable for us to warn on this kind of example, e.g., placing a Void result of a call to a mutating method in a variable. Can you file a ticket a bugs.swift.org? It would be a great starter bug.

  - Doug

Ticket created. SR-1288

···

On 21.04.2016 6:57, Douglas Gregor wrote:

On Apr 19, 2016, at 12:41 AM, Vladimir.S <svabox@gmail.com> wrote:

On 19.04.2016 0:18, Douglas Gregor via swift-evolution wrote:

Proposal
link: https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md

Hello Swift Community,

The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs
Accordingly” ran from March 31...April 5, 2016. The proposal is *accepted*.

There was much debate, both before and during the review, over the
“InPlace” suffix/ “form” prefix, and at this point any answer will be
objectionable to some. The core team has opted to accept the proposal
as-is, keeping the “form” prefix to describe the mutating counterpart to an
operation naturally described by a noun (e.g., “formUnion” for the mutating
variant of “union”), for the reasons described in the proposal itself.
Thanks all for the spirited discussion!

- Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution