New features for Swift 3

Original: What's New in Swift 3? , Ben Morrow, translator: kmyhy

The Swift 3 will be launched in the second half of this year, bringing a lot of core code changes to swift developers. If you're not looking at the Swift Evolution project, you might wonder what's changed in Swift 3, how it will affect your code, and when you can port code to Swift 3. This article will answer questions for you!

In this article, I'll focus on the major changes in Swift 3 and the profound impact these changes have on your code. Let's get started!

Begin

Currently, the Swift 3 preview is available only in the Xcode 8 beta release. In the coming months, Swift 3 is still changing, and there are some changes. At the end of 2016, when Xcode GM was released, the new features of Swift 3 would be stable. So developers have to be calm until then to submit apps written in Swift 3 to the app Store.

To make it easier for developers to migrate code to Swift 3, Apple added a swift version to Xcode 8, the Swift 2.3, which made a minor upgrade to Swift. If you are a developer, Swift 2.3 and 2.2 are not really different, but Swift 2.3 can support the various new SDK and Xcode features mentioned in this WWDC. When you launch the beta version of Xcode 8, you can submit your app with Swift 2.3来 instead of migrating the code to Swift 3.

I recommend that you test the new features discussed in this article in Playground, and you can test migration Assistant with one of your projects so that you know about these changes. Since you can't submit apps to the app Store until the next version of Xcode 8 beta and SIWFT 3 is officially released, I recommend that you do not say code migration to Swift 3 for now.

Upgrade to Swift 3

Upgrade to Swift 3 o'clock and you'll find that basically every file needs to be changed! This is because all the Cocoa API names have changed. In short, the API is still the original API, but this API is called in Objective-c, and in Swift is another term. The syntax of Swift 3 is written more closely to the natural language.

In Xcode 8, Apple offers the migration Assistant, which can do most of the migration work. Of course, there is still a part of the work you need to do manually.

You can immediately upgrade the code to 2.3 or 3.0. If you need to turn the code back in, you can use Xcode's Edit > Convert > to current Swift Syntax ... Menu. The compiler will be as smart as Migrateion Assistant. If you accidentally use the old API when you invoke the method, the compiler displays a fixt-it option that lets you use the correct new API. Fortunately, Swift 3 will not stop changing the source code until it is finally released. Therefore, you can save your Swift code to a different version. However, the Swift core team cannot guarantee that this will not change, and if at some point it is not guaranteed to be compatible with the source, they will provide a longer transition period. This means that the source code is stable so that more conservative companies can be encouraged to use it.

This also shows that the goal of binary stability has not yet been achieved. The implications of this will be discussed at the end of this article.

The implemented Swift Evolution offer

Since Swift Open source, community members have submitted more than 100 recommendations for improvement. Most (more than 70) of these proposals have been accepted after the discussion has been revised. Still others have been rejected after a heated debate. But in the end, all the proposals go through the core team's final decision.

Collaboration between the core team and the wider community is fruitful. In fact, Swift has gained more than 30,000 stars on Github. New proposals are submitted every week, JoJo. Even Apple's engineers will submit their proposals on Github.

In the next section, you'll see some annotations like [SE-0001]. This is an accepted proposal number and will be implemented in the final version of Swift 3.0. Each proposal is marked so that you can see the specifics of each change.

Changes to the API

The biggest change in Swift 3 is that the standard library uses a unified naming method in each library. These rules are included in API Design guidleines, which is used by the core team when building Swift 3, which is highly readable and easy to use for beginners. The core team follows the principle that a good API design should always look at the problem from the caller's point of view. They strive to make the API easy to use. No more, let's start by talking about the changes that are so important to you.

The label of the first parameter

We start with an example that a developer will use in Swift every day.

The first argument in a function or method must now have a label unless you explicitly declare it not. Previously, when we called a function or method, we could ignore the label[se-0046 of the first argument]:

// old way, Swift 2, followed by new way, Swift 3
"RW".writeToFile("filename", atomically: true, encoding: NSUTF8StringEncoding)
"RW".write(toFile: "filename", atomically: true, encoding: NSUTF8StringEncoding)
SKAction.rotateByAngle(CGFloat(M_PI_2), duration: 10)
SKAction.rotate(byAngle: CGFloat(M_PI_2), duration: 10)
UIFont.preferredFontForTextStyle(UIFontTextStyleSubheadline)
UIFont.preferredFont(forTextStyle: UIFontTextStyleSubheadline)
override func numberOfSectionsInTableView(tableView: UITableView) -> Int
override func numberOfSections(in tableView: UITableView) -> Int
func viewForZoomingInScrollView(scrollView: UIScrollView) -> UIView?
func viewForZooming(in scrollView: UIScrollView) -> UIView?
NSTimer.scheduledTimerWithTimeInterval(0.35, target: self, selector: #selector(reset), userInfo: nil, repeats: true)
NSTimer.scheduledTimer(timeInterval: 0.35, target: self, selector: #selector(reset), userInfo: nil, repeats: true)

Note that some methods use the preposition "of", "to", "with" and "in" as external parameter names. This is to increase the readability of the code.

If this method does not use a preposition and does not use a label, you should explicitly precede the first parameter name with an underscore when the method is defined:

override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { ... }
override func didMoveToView(_ view: SKView) { ... }

In many programming languages, many methods can share a method name, but the name of the parameter differs. Swift is no exception, and now you can overload methods that APIs will be able to convert directly into appropriate calls. Here is an example that shows two overloaded forms of the Index () method:

let names = ["Anna", "Barbara"]
if let annaIndex = names.index(of: "Anna") {
print("Barbara‘s position: \(names.index(after: annaIndex))")
}

The method name is the same, but the parameter name is different, which makes it easier to remember.

Omit unnecessary words

In the early Apple standard Library, the method name contains a word that indicates the return value of the method. Because Swift compiles support type inference, this practice is not necessary. The core team filters out all the "noise" as much as possible, so the duplicate words are removed, leaving only the most important part of the method name.

The API has become smarter in translating the Objective-c library into a cost-effective Swift language [SE-0005]:

// old way, Swift 2, followed by new way, Swift 3
let blue = UIColor.blueColor()
let blue = UIColor.blue()
let min = numbers.minElement()
let min = numbers.min()
attributedString.appendAttributedString(anotherString)
attributedString.append(anotherString)
names.insert("Jane", atIndex: 0)
names.insert("Jane", at: 0)
UIDevice.currentDevice()
UIDevice.current()

The new GCD and Core Graphics

The legacy of the "Elder" API,GCG and Core Graphics need to be re-"dressed up".

The Grand Central Dispatch is often used for long-time calculations or for communicating with servers. You can avoid blocking the user interface by putting tasks on different threads. The Libdispatch library is written in C and provides a C-style API. This API is now redesigned as [SE-0088] in Swift:

// old way, Swift 2, followed by new way, Swift 3
let blue = UIColor.blueColor()
let blue = UIColor.blue()
let min = numbers.minElement()
let min = numbers.min()
attributedString.appendAttributedString(anotherString)
attributedString.append(anotherString)
names.insert("Jane", atIndex: 0)
names.insert("Jane", at: 0)
UIDevice.currentDevice()
UIDevice.current()

The same is the case with the Core Graphics. The Core Graphics are written in C and have been called only in "ugly" functions. This is its new usage [SE-0044]:

// old way, Swift 2
let ctx = UIGraphicsGetCurrentContext()
let rectangle = CGRect(x: 0, y: 0, width: 512, height: 512)
CGContextSetFillColorWithColor(ctx, UIColor.blueColor().CGColor)
CGContextSetStrokeColorWithColor(ctx, UIColor.whiteColor().CGColor)
CGContextSetLineWidth(ctx, 10)
CGContextAddRect(ctx, rectangle)
CGContextDrawPath(ctx, .FillStroke)
UIGraphicsEndImageContext()
// new way, Swift 3
if let ctx = UIGraphicsGetCurrentContext() {
    let rectangle = CGRect(x: 0, y: 0, width: 512, height: 512)
    ctx.setFillColor(UIColor.blue().cgColor)
    ctx.setStrokeColor(UIColor.white().cgColor)
    ctx.setLineWidth(10)
    ctx.addRect(rectangle)
    ctx.drawPath(using: .fillStroke)
    UIGraphicsEndImageContext()
}

Case value in Enumeration

Another difference from the previous Swift code is that the case value defined in the enumeration now uses the small hump nomenclature. This is for consistency with the property name or variable name [SE-0006]:

//old way, Swift 2, followed by new way, Swift 3
UIInterfaceOrientationMask.Landscape
UIInterfaceOrientationMask.landscape
NSTextAlignment.Right
NSTextAlignment.right
SKBlendMode.Multiply
SKBlendMode.multiply

The Uppercamelcase nomenclature is now used only on type names and protocol names. When you get used to all this, the SWIFT team is not in vain for the pursuit of consistency.

Method of returning a value or modifying a value

The rules for using verbs and nouns in the method names in the standard library are also more uniform. You should follow the results of this method or take some action to name the method. The first principle is that if the method name contains an "ed" or "ing" suffix, it is a noun. Method with the name of a noun has a return value. If you do not include these suffixes, it is likely that this is a verb. A verb-named method takes some action on a block of referenced memory. The so-called "Modify a value". Here are a few ways to match the noun/verb naming rules [SE-0006]:

customArray.enumerate()
customArray.enumerated()
customArray.reverse()
customArray.reversed()
customArray.sort() // changed from .sortInPlace()
customArray.sorted()

Here are some snippets of code that use these methods:

Var ages = [21, 10, 2] // variable, not a constant, so you can modify it
Ages.sort() // modify the value, now the value becomes [2, 10, 21]
For (index, age) in ages.enumerated() { // "-ed" is a noun indicating that an ages copy will be returned
Print("\(index). \(age)") // Print: 1. 2 \n 2. 10 \n 3. 21
}

function type

When a function is declared and called, it is required to enclose the argument in parentheses:

Func f (a:int) {...} F (5)

However, when you use a function type as a parameter, you might write code like this:

Func g (a:int, int), int, int  {...}//old, Swift 2

You'll find the code hard to read. Where does the parameter end, and where does the return value start? In Swift 3, the correct way to define this is [SE-0066]:

Func g (a:int, int), int, int  {...}//old, Swift 2

The parameter list is now wrapped in parentheses and then the return type. Things are easy, and function types are easier to identify. By the following comparison, you will be more clear:

// old way, Swift 2
Int -> Float
String -> Int
T -> U
Int -> Float -> String
// new way, Swift 3
(Int) -> Float
(String) -> Int
(T) -> U
(Int) -> (Float) -> String

New features in API

In addition to the biggest change to the existing API "old bottle new"-There are a lot of swift communities working on this, as well as some functional additions to the Swift API.

Accessing the owning type

When you define a static property or method, you call them directly from the class or type:

Customstruct.staticmethod ()

If you are currently writing code inside the type, still use the type name to invoke the static method. To make the presentation clearer, you can now refer to the type that the current instance belongs to by self. The self in uppercase is a reference to the type of the current instance, while S is lowercase to reference the current instance itself.

This is a concrete example [SE-0068]:

struct CustomStruct {
  static func staticMethod() { ... }
  func instanceMethod() {
    Self.staticMethod() // in the body of the type
  }
}
let customStruct = CustomStruct()
customStruct.Self.staticMethod() // on an instance of the type

In-line sequences

Sequence (first:next:) and sequence (state:next:) is a global function that returns an infinite sequence. You pass them an initial value or a mutable state that will later invoke the code in the closure [SE-0094]:

for view in sequence(first: someView, next: { 0.superview }) {
// someView, someView.superview, someView.superview.superview, ...
}

You can also use the prefix operator to add a limit to a sequence [SE-0045]:

for x in sequence(first: 0.1, next: { 0 * 2 }).prefix(while: { 0 < 4 }) {
// 0.1, 0.2, 0.4, 0.8, 1.6, 3.2
}

Miscellaneous

• KeyPath () is equivalent to #selector () to help you reduce input errors

• You can invoke pi on certain types, such as: Float.pi, Cgfloat.pi. Most of the time the compiler can infer the type: let circumference = 2 *. pi * radius [SE-0067]

• The NS prefix is removed from the old Foundation type and can now be replaced with Calendar, date, Nscalendar, nsdate

Improvement of tools

Swift is a language, and most of the time you can't leave the development environment in which it is written-for Apple developers, that is xcode! Changes in tools affect the way you write your code every day.

Swift 3 Fixes bugs in the compiler and IDE, and improves the accuracy of reporting errors and information. As you would expect, the release of each release will make Swift and the compiler run faster:

• Improved Hash algorithm for strings, resulting in a 3 times-fold increase in performance after a string is stored in a dictionary

• Move objects from the heap to the stack, resulting in a 24 times-fold increase in performance (in some cases)

• The compiler can cache multiple files at once (in case the entire module is optimized)

• The size of the code is optimized, resulting in a smaller compilation size for Swift code. In the case of Apple's Demobots, the compilation size is reduced by 77% of the original size.

Xcode will also be more intelligent in understanding Swift code:

• In the past, when you right-clicked on an API method such as sort () and jumped to the definition, you would see a header file that was not easily understood. Now, in Xcode 8, you'll see that the sort () method is actually an extension of the Array class.

• Swift snapshots, as the Swift Evolution released tonight, said. Before fully merging to Xcode, snapshots provides an opportunity to use the new syntax. Xcode 8 is capable of loading and running Swift snapshots in Playgournd.

Swift Package Manager

Open source Swift actually contains the swift language itself, the core library, and the package manager. Together, these three constitute the Swift we have seen. The SWIFT Package Manager defines a simple directory structure that includes the SWIFT code that you share and import into your project.

Similar to the package managers you have used Cocoapods or Carthage, Swift Package Manager downloads dependencies and compiles them, link them to accomplishment or executable files. There are already 1000 libraries that support the Swift Package Manager, and more libraries will support it in the coming months.

Features in the plan

As mentioned earlier, Swift 3 avoids incompatible changes as much as possible so that your code can be compatible from one version to the next. If this is true, then there should be some more ambitious goals in this release, namely, generics enhancement (generic additions) and ABI (program binary interface) are stable.

Generic enhancements include recursive protocol constraints and the ability to conform a constrained extension to a new protocol (for example, an array for storing equatable objects should also comply with the Equatable protocol). Before these features have been implemented, Swift cannot be considered an ABI stable.

ABI stabilization requires applications and libraries to be able to interact with each other regardless of which version of the compiler is compiled. This is an important step forward for third-party libraries, because this allows the framework to be encapsulated without the need to provide the source code, and now the new version of Swift does not only need these third-party libraries to modify the codes, but also to recompile.

In addition, if the ABI is stable, you can remove the Swift standard library contained in the binaries, because IOS and MacOS apps are now created with Xcode. Current binaries contain about 2 MB of file size in order to ensure compatibility with future operating systems.

In short, you can only keep the source code version compatible now, and binary version compatibility is still not possible at the moment.

End

Swift is still evolving because the community's goals are best practices. Although it is still young, it also faces tremendous opportunities and a bright future. Swift is now able to run on Linux, and in the next few years you will see it running on more servers and devices. Designing a language from scratch will inevitably undermine ABI stability, which becomes much smaller once it stabilizes. This (open source) is the only chance to make this language better, otherwise we will regret it.

Swift is expanding its reach. Apple is taking it personally. Apple's team is using Swift in the Music app, Console, Sierra Pip, Xcode Document Viewer, and the new IPad version of the Swift Playground app.

Here, Apple seems to have a way for non-programmers to learn swift intentions, such as the ability to use Swift on IPAD and some educational measures to demonstrate this.

In addition, Swift is continually improving: naming becomes more canonical, code reads clearer, and you can use tools to migrate code. If you want to learn more, see WWDC's conference video.

To be sure, the official release of Swift 3 at the end of 2016 will certainly be expected. We will continue to follow up on all changes, and please stay tuned for our tutorials, new book previews and videos, and we'll start using these exciting improvements.

This article transferred from: http://www.cocoachina.com/swift/20160712/17028.html

New features for Swift 3