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!
Just wanted to go back to
Apply API Guidelines to the Standard Library SE-0006
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:
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!
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:
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!
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:
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!