Some new features of Swift 3.1

Apple has finally released Xcode 8.3 and Swift 3.1. If you don't have time to read through the release note carefully, at least some of the new features in Swift 3.1 are worth knowing, so we've created a free content series. Of course, Swift 3.1 and Swift 3 are compatible at the source level, so if your project has been updated to Swift 3, this update should not cause you too much trouble. However, Xcode 8.3 removes the support for Swift 2.3, so if you're still on the earlier version of Swift, it's good to be updated with caution.

Next, let's briefly introduce the content in this series.

SE-0080 failable Initialize of numeric types

This is an improvement brought about by SE-0080. For example, before, when we put a Double forced conversion Int , Swift will automatically cancel the part after the decimal point. This is useful when we need to perform a "lossless" precision conversion between different numeric types, and the method returns us when the transformation leads to loss of precision init(exactly:) nil . We show you the specific use of this feature through one of the most common scenarios: parsing the JSON returned by the server.

SE-0045 of the two new filter elements added in sequence

prefix(while:)And the drop(while:) two API methods that are newly added to the type in Swift 3.1 Sequence , through which you can help us write more efficiently Sequence how to filter elements in. In particular, if we were to filter the elements in an infinite sequence, they would be more convenient.

SE-0103 temporarily converted to escaping closure

As described in SE-0103, in Swift 3, the function's closure type parameter is changed from escaping to non-escaping by default. This is well understood, since most of the closure parameters used for functional programming do work in a non-escaping way.

But this proposal also mentions the problem that sometimes we need to pass the closure of the non-escaping attribute to a function that requires the closure of the escaping attribute. When do you need this kind of scene? Perhaps the explanation you see elsewhere is that this is a less common use.

SE-0141 constrained Swift version via available

Although we can achieve version control through the form of # If, we have a less convenient place to write libraries in this way. Each swift version that the compiler wants to support is compiled independently. So, if multiple swift versions are compatible between a swift ABI cumulative update, it is a cumbersome task to carry a library of these days. A better approach, of course, should be to compile only once, and then build the library containing the swift versions that each API can support.

For this reason, the Swift 3.1 has @available been extended to allow us not only to constrain the operating system, but also to specify the version of Swift.

SR-1009 using representational type constraint generic parameters

In Swift 3.0, if we were to add to a particular type Optional extension , it was not an easy thing to do. We have to protocol simulate a constraint of an image type by constraining a computed property of the same type. But in Swift 3.1, this flaw is made up, and we can not only constrain the use of generic parameters, but protocol also use the representational type as a type constraint, which is a bit like the template-biasing technique in C + + generics.

SR-1446 two improvements to inline types

In this section, let's talk about topics related to inline types. In Swift 3.1, there are two improvements to the inline type:

• An inline type of a normal type can use a generic parameter of its outer type directly, at which point it is still a normal type;

• An inline type of a generic type can have a generic parameter that is completely different from its peripheral type;

Some new features of Swift 3.1