What’s new in Swift 3.0?

If you think the changes from 1.2 to 2.0 are already "scary"; then you will be surprised with this 3.0 version. With Swift 3.0, you will see a 180o change, the previous version's code will not build if you do not change it accordingly.

In this article, although I cannot mention all the changes of the new version, I will try to share some important changes along with specific examples.

WARNING # 1: Swift 3.0 is still in development. The article will continuously update the latest changes.

WARNING # 2: There are many big and small changes. It seems that this is a stable "milestone" version for years to come, and the next versions will change less.

WARNING # 3: The inadequate features in version 2.2 have been removed: ++, -, C-style loop, tuple splat syntax, …

All function parameters have labels (names)

In Swift 2.0, we witnessed a change in the function call (function) and method (method). And with version 3.0, we will see this change again, at a higher level. From Swift 2.x and earlier, the method name does not require the label in the first parameter, so the name of the first parameter is always attached to the method name. For example:

Swift 3 will by default require a parameter label (you can adjust it to change it), meaning that the method name will no longer detail the parameters. In fact, the end of the function name will often turn into the name of the first parameter.

To illustrate more clearly, here is a code in Swift 2.2 with a corresponding example in Swift 3:

This is the method you call, while also causing a domino effect for methods gọi: When you are talking to a number of frameworks such as UIKit, the method will follow the rules of "no name parameter" seed previous versions (this applies even to Swift 3).

Here are some typical examples in Swift 2.2:

With Swift 3, all need underscore (_) before the first parameter, to signal that the caller (Objective-C code) will not use parameter labels:

Remove unnecessary words

When Swift turned into open source in December last year, Swift's guildlines API anticipated a change of version 3 with three words: "omit needless words" (eliminating unnecessary words). And now that we have seen this change in Swift 3, the method name will remove obvious words.

First of all, let's look at a few simple examples in Swift 2.2:

Do you identify redundant words? When you work with UIColor, blue is obviously colored, so blueColor () is no longer needed. When you join attributed string together, do you need to determine that you are append a attributed string rather than an elephant?

Here is the corresponding code in Swift 3:

As you can see, the method name is much shorter!

This change particularly affects the string (there are many repeating structures). For further clarification, the following is a direct comparison, the top line of Swift 2.2 and the bottom line of Swift 3.0:

Note : capitalized is still an attribute, but lowercaseString and uppercaseString have converted to lowercased () and uppercased () methods.

I chose the above examples because the jump to Swift 3 is not too long, but there are still many different changes that make me "hurt my head" – usually because the last method is too short, unclear as before. .

Eg:

When I saw this code, I thought in my head: "dismiss what?" Perhaps we were too familiar with iOS programming so far. But when you reverse the change of the parameter label and "add" the unnecessary words, you can see, it is no different from Swift 2.2:

prepareForSegue () has the same change, now we have:

lowerCamelCase replaces UpperCamelCase with enum and property

Although not relevant (in terms of syntax), but how to use capital letters in class names, struct, property, enum, … still often follow a convention: class, struct and enum using UpperCamelCase (MyStruct, WeatherType.Cloudy), property and parameter name using lowerCamelCase (emailAddress, requestString).

However, there are some exceptions, and these exceptions will no longer exist in Swift 3: properties and parameters that start with abbreviations will now use lowerCamelCase.

This change is sometimes not too strange: Swift 2.2 uses NSURLRequest (URL: someURL) to create the NSURLRequest object – notice the capitalized" URL ". Swift 3 will rewrite to NSURLRequest (url: someURL), and also mean you will have to use commands like webView.request? .Url? .AbsoluteString to read the URL of a web view.

Are you uncomfortable when the property name changes to "half lean half fat", where the flower, the place is usually, like: CGColor or CIColor? You guessed it wasn't wrong: in Swift 3, they turned into cgColor and ciColor, when included in the code:

This change will increase consistency: all properties and parameters will start with lowercase letters, and there will be no exceptions.

At the same time, enum case also changes, from UpperCamelCase to lowerCamelCase. In my opinion, this change is quite correct: enum is a data type (like struct), but enum value is closer to property. In other words, all Apple enum you use will now be lowercase:

This small change leads to a bigger change because Swift's optionals are actually enum, like:

This means if you use .Some when working with optionals, you need to convert to .some. Of course, you can take this opportunity to completely remove .some – the following two codes have the same function:

Swifty importing of C functions

Swift 3 also introduced attributes for the C language, allowing library creators to designate new ways to enter code into Swift quickly and accurately. For example, all functions starting with "CGContext" will be mapped to the properties and methods on a CGContext object. In other words, the "ugly warts" CGContextSetFillColorWithColor () has finally been removed.

To see more clearly, here is an example in Swift 2.2:

In Swift 3 CGContext can be considered an object that you can call the method, without having to repeat CGContext continuously. So, we can rewrite the above code as follows:

Note: In Swift 2.2 and 3.0, UIGraphicsGetCurrentContext () will return CGContext optionally, but since Swift 3.0 uses call methods, we must unwrap carefully before using.

You can also see the mapping of this C function in many other cases: for example, you can now read the numberOfPages property of a CGPDFDocument. And CGAffineTransform has also improved significantly. Here are some old and new examples:

Verbs and nouns

Perhaps reading here many people will jump to the end immediately. Don't get it, this part is equally important.

Here are some quotes from Swift API guildelines:

  • "When the operation is described with a verb, use the verb form command with the mutating method and add the" ed "or" ing "suffix to name the corresponding non-mutate methods."
  • "Should use the past verb form of the verb to name the non-mutate variable"
  • "When adding" ed "is not grammatical because the verb has a direct object, use the verb's present participle to name the non-mutate variable"
  • "When the operation is described by noun, use the noun with the non-mutate method and add the" form "prefix to name the mutated mothod"

Not surprisingly, the rules in Swift are increasingly associated with increasingly more linguistic terms (because Swift is a kind of "language"). However, this can cause many difficulties for you weak English, because many method names will have many changes.

Let's start with a few examples:

Each time Swift 3 adjusts the method with "d" added to the end: this is the value returned.

This special rule makes it easy to confuse the array arrangement. Swift 2.2 uses sort () and returns the sorted array, and sortInPlace () to sort the array in place. In Swift 3.0, sort () changes to sorted () as the above example, and sortInPlace () changes to sort ().

You have to be careful because sort () in Swift 2.2 returns the array sorted, and sort () in swift 3.0 reorganizes the array in place.

So much change to do?

With just a few small changes, it's hard for us to get used to. So what is the point of changing this? In fact, I may not realize it, but these changes are Apple's attempt to make the language easier to learn, easier to use, and faster (especially for beginners).

These changes are not Apple's "outburst" idea either. These are all community opinions, thoroughly discussed before being "approved" by Apple 3.0 in Swift 3.0.

If you want, you can also contribute and discuss ideas , contribute to the future and "destiny" of the Swift language.

Tecktalk via hackingwithswift

Share the news now