What’s new in Swift 3? (part 1)
Swift 3 appeared to give Swift dev changes in code. If you haven't followed the Swift Evolution project thoroughly yet, you might wonder what store changes are, how it affects the code, and when you should start converting code to Swift 3. The article will emphasize the most important changes in Swift 3 affecting your code.
Getting Started
Swift 3 preview is available in Xcode 8 beta released on June 15. While the upgrade of Swift 3 is expanding, there are still some changes that are accepted in the coming months. The end of the new features will happen when Xcode reaches GM at the end of 2016, so you'll need to wait until then to bring the Swift 3 apps to the App Store. To make it easier for devs to join Swift 3 on specific terms, Apple has included Swift 2.3 as a minor update with Xcode 8. Swift 2.3 with support for SDKs and Xcode features announced at WWDC . When Xcode 8 is out of beta, you will be able to post apps using Swift 2.3 if you are busy and haven't switched to Swift 3 yet.
The writer encourages devs to test the features discussed in the playground and even run the Migration Assistant with one of your projects, so you can feel the changes. But since it is impossible to launch an app on the App Store until Xcode 8 is no longer beta and Apple locks Swift, you may need to wait for more time to transcode to Swift 3.
Switch to Swift 3
When switching to Swift 3, note that all files also need to be changed. For example, all the Cocoa API names have changed or the API is still the same but there is a name suitable for Objective-C and a name suitable for Swift. Swift 3 is planning to make writing Swift language more natural in the coming years.
Apple has integrated Migration Assistant with Xcode 8 to take advantage of most changes at the same time. Don't be surprised if you need to make some changes yourself if the migrator doesn't solve it automatically.
You can switch to Swift 2.3 or Swift 3 immediately. If you need backup, navigate in Xcode to Edit> Convert> To Current Swift Syntax …. Luckily, the compiler is pretty smart, similar to the Migration Assistant. If you accidentally use the old API on a call method, the compiler will suggest the Fix-It option, which will help you use the correct API.
The best news is that Swift 3 is intended to be the final release with major source changes. At that time, you could keep your Swift code in every version. While Apple's Swift team could not predict the future, they promised that if they needed to break down the compatibility of the source, they would propose a longer degradation life. That means that language has gained stability in source, encouraging more traditional companies to accept language.
In general, the goal of achieving binary stability has not yet been achieved and you will realize the effect of this at the end of the article.
The Swift Development proposals have been implemented
Community members have sent more than 100 proposals for Swift changes since Swift is open source. Approximately 70 prams have been accepted after discussion and adjustment. The rejected projects have also raised some serious discussions, but the Swift team still made the final decision for the proposal.
The collaboration between the team and the wider community is quite impressive. In fact, Swift received 30,000 stars on Github. Many new proposals have been uploaded every week, week after week. Even Apple engineers write proposal on open Github repository when they want to make changes. In the sections below, you will see linked tags like [SE-0001]. Here are the number of proposals Swift development is accepted and will be implemented as soon as the Swift 3 version is finally released. The links to each proposal have been included so you can find out details about each change.
API changes
The biggest update in Swift 3 involves standard libraries that accept consistent naming conventions throughout libraries. The API Design Guidleines tutorial includes the principles that Apple's Swift team must address when the team is building Swift 3, ensuring a higher value for reading and accessibility for new developers. The group worked on the principle that "Good API design always considers call site". They tried to bring clarity to the point of use.
Specifically, these are the most likely changes that affect you, the iOS dev.
First Parameter Label
Let's start with the direct reversal of a practice you use every day in Swift.
If you don't require another, the first parameter in the current functions and methods has 1 label. Previously, when you called a function or method, you omitted the first parameter label [ SE-0046 ]:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | // 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 how method definitions use prepositions such as "of", "to", "with" and "in" for external names. This is part of an effort to optimize readability. If the method calls for good reads without a preposition and does not need a label, you should exclude 1 to explicitly specify the first parameter name with an underscore:
1 2 | override func tableView (_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {...} override func didMoveToView (_ view: SKView) {...} |
In many programming languages, methods can share a base name and suggest different parameter names. Swift is no exception, now you will encounter more overloaded method names because APIs are translated more directly. This is an example of two forms of index ().
1 2 3 4 | let names = ["Anna", "Barbara"] if let annaIndex = names.index (of: "Anna") { print ("Barbara's position: (names.index (after: annaIndex))") } |
In addition, changes in parameter names also make the method more uniform and easier to learn.
Remove unnecessary words
In the iterative iterations of the previous Apple library, the method consists of a name implying their return value. Because of the Swift compiler's type checking capability, this becomes less necessary. The Swift team tried to figure out how to filter all the noise so that only the signals remained and so many repeated words were removed.
The API is smarter when libraries are converted to the original Swift [ SE-0005 ]:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | // 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 () |
ITZone via IDE Academy