Other New Swift 2 Features

Paul Hudson:

When a method runs, you want to be sure that it has all the data it needs to work properly, and your code should only execute when that’s the case. Coders solved that in common two ways: pyramids of doom and early returns.

Eric Cerney:

Using guard solves all 3 of the issues mentioned above:

1. Checking for the condition you do want, not the one you don’t. This again is similar to an assert. If the condition is not met, guard‘s else statement is run, which breaks out of the function.
2. If the condition passes, the optional variable here is automatically unwrapped for you within the scope that the guard statement was called – in this case, the fooGuard(_:) function. This is an important, yet notably strange feature that really makes the guard statement useful.
3. You are checking for bad cases early, making your function more readable and easier to maintain.

Paul Hudson:

In Swift 2, Apple introduced API availability checking. If you set your app’s Deployment Target to a lower iOS release than the base SDK, Xcode will automatically scan every API you use to make sure it’s available in your lowest deployment target version. This information has been in Apple’s API headers for years, but it’s only now being exposed to the compiler. What it means is that if your app compiles, you can be guaranteed it doesn’t call any code that can’t run because of missing APIs.

[…]

In that code, #available is going to check whether we’re on iOS 9 or later, or any other unknown platforms like watchOS – that’s the * at the end, and it’s required. And that’s it: all the code you’ll put in place of "// use UIStackView" effectively has elevated rights to use iOS 9.0-only technology, whether that’s classes, methods or enums.

Finally.

Natasha Murashev on unwrapping multiple optionals using pattern matching:

I was at first frustrated by the use of ? to indicate that the value does exist (especially since I associate it with the idea of optionals, where the value may or may not exist), but I have to admit that this example is very clear to understand. And I definitely like it as a much better alternative to the clunky .Some(username) syntax.

Chris Eidhof:

Inspired by Mike Ash’s tweet, I tried generating JSON dictionaries in Swift by using the new reflection features.

[…]

We can provide a default implementation by extending the protocol. This default implementation reflects a value, and loops over the children, recursively serializing them as well. If the type doesn’t have any children, we assume it’s a primitive (e.g. a String or an Int) and don’t serialize it.

Mike Ash:

The terrible world of CFunctionPointer is gone in Swift 2. Instead, Swift function types have trifurcated into variants. Any Swift function type can optionally be annotated with a @convention specifier which says what kind of function it is. The swift convention is the default and indicates a normal Swift function. The block convention indicates an Objective-C block type. These were automatically bridged, and still are, but now the typing is more explicit. Finally, the c convention indicates a C function pointer. Function types annotated with @convention(c) still behave mostly normally, so you can call them and pass them as usual.

Natasha Murashev:

The idea behind for…in filtering is that now you can do filters inline vs in your for loop.

[…]

Note that you can use the pattern matching with “if case” in combination with the for…in filtering for some even more advanced filtering!

I’d still like to see list and dictionary comprehensions.

iOS Language Design Mac Programming Swift Programming Language

1 Comment RSS · Twitter

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ