Today, Apple accepted (with some modifications) three major internally-driven proposals. They are:

• SE-0005 Better Translation of Objective-C APIs Into Swift
• SE-0006 Apply API Guidelines to the Standard Library
• SE-0023 API Design Guidelines

Developed by the core Swift team, all three sculpt the way Swift defines itself as a language and how developers will express Swift conventionally moving forward.

The API Design Guidelines (SE-0023) leads off, establishing best practices guidance for Apple standard style. Most of this is pretty straight forward. Much of the advice is excellent. Some things I have small issues with. You as a developer are free to embrace as much or as little as you desire.

The automatic translation effort (SE-0005) has dropped its effort to strip NS from the start of API names (for the moment, a revised version will return as its own proposal).  It adopts the API guidelines in bringing Cocoa signatures into the Swift world. Get a sense of how these APIs will translate by visiting the review repository, which offers projections into Swift 2 and 3.

One significant part of the proposal was the removal of the “NS” prefix from Foundation APIs in Swift. This name change was considered problematic for several reasons, the most-often-cited one being that the reference-semantic nature of many Foundation types conflicted with the Swift standard library’s value-semantic types. The “NS” prefix removal part of this proposal has been removed from the accepted proposal. A revised version of this will come back as its own proposal, taking into account the feedback received.

Finally, the Standard Library update effort (SE-0006) establishes how Swift looks to itself, and how the methods in the standard library will conform to the recommendations in the new API guidance.

The proposed changes are massively source-breaking for Swift code, and will require a migrator to translate Swift 2 code into Swift 3 code. The API diffs from this proposal will be the primary source of the information about the required transformations. In addition, to the extent the language allows, the library will keep old names as unavailable symbols with a renamed annotation, that allows the compiler to produce good error messages and emit Fix-Its.

In accepting this proposal, Apple notes two important changes:

Most of the modifications to the proposal involve tracking changes to the Swift API Design Guidelines (SE-0023), especially:

• Adoption of first argument labels throughout the Standard Library.
• Lower-casing of enum case names, including “.some(x)” and “.none” for the all-important Optional type.

First-argument labels are something that have evolved first from Swift 1 to a more Objective-C like Swift 2 and now to a more Swift like Swift 3. They’ve reached a state that’s somewhere between pure C and pure Objective C, hopefully with a better balance than the previous two incarnations.

For example:

-  func advancedBy(n: Distance, limit: Self) -> Self
+  func advanced(by n: Distance, limit: Self) -> Self

-  func distanceTo(end: Self) -> Distance
+  func distance(to end: Self) -> Distance

Enumeration cases will now be treated like any other static members, and use consistent lower camel case naming.

An extensive diff list can be found in the updated proposal.