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
- March 31…April 5, 2016 SE-0056: Allow trailing closures in
guard
conditions - March 31…April 5, 2016 SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly (See also: Stop the Madness and fix the Swift API guidelines.)
- April 7…13, 2016 SE-0063: SwiftPM System Module Search Paths
- April 10…18, 2016 SE-0065: A New Model For Collections and Indices
Proposals awaiting scheduling
- SE-0012: Add
@noescape
to public library API - SE-0017: Change
Unmanaged
to useUnsafePointer
- SE-0025: Scoped Access Level
- SE-0032: Add
find
method toSequenceType
- SE-0041: Updating Protocol Naming Conventions for Conversions
- SE-0030: Property Behaviors
- SE-0045: Add scan, takeWhile, dropWhile, and iterate to the stdlib (Proposal Spotlight for SE-0045 is here.)
- SE-0052: Change IteratorType post-nil guarantee
- SE-0060: Enforcing order of defaulted parameters
- SE-0061: Add Generic Result and Error Handling to autoreleasepool()
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?
SE-0030 “Property Behaviors” was rejected, but the swift team is open for reconsideration of a refined proposel in the (distant?) future. http://thread.gmane.org/gmane.comp.lang.swift.evolution/7735