Swift 1.2
Today Swift 1.2 was released as part of Xcode 6.3 beta. This beta release includes a significantly enhanced Swift compiler, as well as new features in the Swift language itself. For the complete list of changes, read the release notes.
There’s lots of good stuff here, and it’s really impressive how quickly Apple is moving. Some highlights are performance improvements (especially with the optimizer off), a set data type, and a fix for the pyramid of doom.
In Swift 1.2, Objective-C classes that have native Swift equivalents (
NSString,NSArray,NSDictionaryetc.) are no longer automatically bridged. That means passing anNSStringto a function that expects aStringwill now fail![…]
If you’re maintaining Objective-C code, there are some new qualifiers for you to use when specifying the type for arguments, variables, properties, etc. […] If you don’t have Objective-C code to maintain, you’ll still benefit from Apple adding these qualifiers to the Cocoa headers. That will make your Swift experience that much cleaner with fewer implicitly-unwrapped values.
Annotating any pointer in an Objective-C header file causes the compiler to expect annotations for the entire file, bringing on a cascade of warnings. Given that most annotations will benonnull, a new#pragmadeclaration can help streamline the process of annotating existing classes. Simply mark the beginning and end of a section of your header with#pragma clang assume_nonnull beginand... end, then mark the exceptions.
Airspeed Velocity covers changes to the standard library, such as:
Since classes in Swift are reference-counted, it ought to be possible to detect if your buffer class is being referenced by more than one struct. But there wasn’t an easy Swift-native way to do this, until 1.2, which introduces
isUniquelyReferencedandisUniquelyReferencedNonObjCfunction calls[…]
Swift now supports building targets incrementally. HELLS yes. It no longer should re-build every single file every single time you add a new punctuation mark somewhere.
Swift’s new (NS-less) arrays no longer work with KVO.
To be expected but rather annoying.
Yeah so Swift NS-less arrays are really the kiss of death to Cocoa bindings in Swift.
Swift 1.2: my code code runs up to 10x faster than 1.1 unoptimized, up to 8x faster optimized.
[Optimized] builds were still 2x~4x as slow as C in my limited tests.
Swift is getting better and faster but it’s still not suitable in the domain space I’m currently working in for this project: high-performance, real-time systems.
On 1.2 Release is about 180-200% faster than Debug.
IIRC 1.x showed larger differences between debug & release.
Adam Kaplan finds that it’s faster, though still slower than Objective-C:
At this stage I’m more than happy to retract my previous conclusion of Swift being too slow for production use. Swift 1.2 seems more than up-to the task and if they keep updates like this one coming, it may even eventually live up to its namesake.
It still has exponential compile times for simple literals, IDE crashes, and there are some new NSString bridging issues.
In 1989 I saw Cocoa (nee NeXTstep) and said, “I’ll spend my life making it so everyone can use this.”
I feel that was about Swift, now.
Update (2015-03-10): Douglas Gregor (via Ken Ferry):
In a recent version of Xcode, Apple introduced an extension to C/C++/Objective-C that expresses the nullability of pointers in the type system via new nullability qualifiers . Nullability qualifiers express nullability as part of the declaration of strchr.
[…]
We’d like to contribute the implementation (and there is a patch attached at the end), but since this is a nontrivial extension to all of the C family of languages that Clang supports, we believe that it needs to be discussed here first.
Update (2015-03-12): Apple:
In general, you should look at
nullableandnonnullroughly the way you currently use assertions or exceptions: violating the contract is a programmer error.[…]
Nullability annotations for C and Objective-C are available starting in Xcode 6.3. For more information, see the Xcode 6.3 Release Notes.
