Erica Sadun

Where technology meets something or other

Triassic Park: The Swift Evolution

Newly Accepted

SE-0048: Generic Type Aliases introduces type parameters that are in-scope for their definition, for example:

typealias StringDictionary<T> = Dictionary<String, T>
typealias DictionaryOfStrings<T : Hashable> = Dictionary<T, String>
typealias IntFunction<T> = (T) -> Int
typealias Vec3<T> = (T, T, T)
typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)

The alias redeclares constraints for its new type. For example, in the string dictionary example, the primary key type must be hashable for this approach to work. The Swift compiler should be adding feedback when expected constraints aren’t found:

typealias DictionaryOfStrings<T> = Dictionary<T, String>
// error: type 'T' does not conform to protocol 'Hashable'

Cool stuff.

SE-0049: Move @noescape and @autoclosure to be type attributes follows the lead of earlier proposals in moving things that describe characteristics of types to the types themselves.

func f(fn : @noescape () -> ()) {}     // type attribute.
func f2(a : @autoclosure () -> ()) {}  // type attribute.

SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations removes a quirky exception that allowed enumeration cases to be referenced without a leading dot in member implementations. In no other case could an instance implementation directly access a static member, and this acceptance removes that exception.

SE-0062: Referencing Objective-C key-paths improves the safety and resilience of key-path code (for both KVC and KVO) using compiler expression checks. The new #keyPath() expression expands at compile time to a  key-path literal string, which is checked for validity.

By having the #keyPath expression do the work to form the Objective-C key-path string, we free the developer from having to do the manual typing and get static checking that the key-path exists and is exposed to Objective-C.

SE-0064: Referencing the Objective-C selector of property getters and setters expands upon SE-0022 to support #selector expressions for properties.

let firstNameGetter = #selector(getter: Person.firstName)
let firstNameSetter = #selector(setter: Person.firstName)

SE-0057: Importing Objective-C Lightweight Generics adds a way that ObjC’s new type parameters can be imported into Swift.

Cocoa and Cocoa Touch include a number of APIs that have adopted Objective-C lightweight generics to improve static type safety and expressiveness. However, because the type parameters are lost when these APIs are imported into Swift, they are effectively less type safe in Swift than in Objective-C

This adoption allows ObjC classes to be parameterized on the types they work with in a manner that’s similar to Swift’s generics syntax.

SE-0063 SwiftPM System Module Search Paths enables Swift to   better import C libraries from locations other than /usr/lib and /usr/local/lib. Support is added for brew and apt-get, and newly introduced `pkgConfigName` entries to specify further search locations through SwiftPM .pc (package configuration) files.

Deferred

SE-0058 Allow Swift types to provide custom Objective-C representations is deferred until after Swift 3. This proposal provides an ObjectiveCBridgeable protocol that allows a Swift type to control how it is represented in Objective-C by converting into and back from an entirely separate @objc type. This frees library authors to create truly native Swift APIs while still supporting Objective-C:

We agree that it would be valuable to give library authors the ability to bridge their own types from Objective-C into Swift using the same mechanisms as Foundation. However, we lack the confidence and implementation experience to commit to `_ObjectiveCBridgeable` in its current form as public API. In its current form, as its name suggests, the protocol was designed to accommodate the specific needs of bridging Objective-C object types to Swift value types. In the future, we may want to bridge with other platforms, including C++ value types or other object systems such as COM, GObject, JVM, or CLR. It isn’t clear at this point whether these would be served by a generalization of the existing mechanism, or by bespoke bridging protocols tailored to each case. This is a valuable area to explore, but we feel that it is too early at this point to accept our current design as public API.

Active Reviews

Proposals awaiting scheduling

Like my posts? Consider buying a book or two. Thanks!

Tweet this Post

2 Comments

  • Are property behaviors something they’re hoping to be able to include in Swift 3, or does it seem like that’s probably out-of-scope?