Wishlist for Swift 3.0
Here’s my shortlist of the features I most want to see added to Swift:
One-to-Many Data Flow
There are only three ways to propagate changes from your data model in off-the-shelf Swift: delegation, NSNotifications, and KVO. Only delegation can be accomplished in pure Swift, but it only works for one-to-one relationships. NSNotifications and KVO are Objective-C hacks that are made available to Swift via bridging, but there are numerous shortcomings with both APIs.
Until there’s a proper first-party alternative, I’ve been using KVO, but that requires making all my essential model classes inherit from NSObject. This feels icky.
I know there are third-party alternatives like ReactiveCocoa, but I don’t trust something that important to a third-party library (e.g. none of the libraries I’ve seen include quality-of-service parameters in their API designs, nor do I trust them to get multi-threading right when tying together changes from a background process to main-thread-only UI code).
Whether or not Apple does a Swift-native “port” of KVO or an Apple-esque rendition of ReactiveCocoa, there’s one thing I’d like them to do regardless: weak collections. Something like NSMapTable, only it would actually work as advertised. Then you could do something like:
var delegates: WeakCollection<MyDelegateProtocol>
i.e. a one-to-many version of the delegation pattern.
Improved Debugger
Maybe I’m missing some key knowledge here, but it seems like the debugger has a lot of room for improvement compared to what it was like with Objective-C. Examples abound. Entering po foo.property.anotherProperty should not choke on optionals as hard as it does currently. po someSwiftDictionary should print something closer to what [NSDictionary description] outputs. Using the expandable-caret view in the debugger for something like a Dictionary is pretty painful, too.
More Flexible Collection Constraints
As long as we’re dependent upon subclassing first-party classes like UIView and UIViewController to build our apps, there’s going to be a need to constrain collections to objects that both inherit from a given class and conform to a given protocol (or protocols). For example, if I have a custom view controller container that queries its children for UI details (the way UINavigationController does), then I want my array of child view controllers to be something like:
public var viewControllers: [MyProtocol<UIViewController>]
Currently, the only alternative is something nasty like:
public var viewControllerItems: [MyProtocol]// ...
protocol MyProtocol { func viewController() -> UIViewController func someOtherMethod() -> UIColor }
In the nasty alternative my view controller subclasses would return self for viewController().
More Flexible Extension Constraints for Collections
It’s currently not possible to extend Dictionary with an arbitrary constraint on the key type. In other words, it’s not possible to do this:
extension Dictionary where Key:String, Value:JSONEncodable {
// blah....
}
This would be helpful when, like the code example suggests, extending Dictionary to aid in JSON encoding/decoding.
Typed Throws
Twitter-friend Benjamin Mayo reminded me of another: we want typed throws. Unless Apple scraps the throws API altogether in favor of something less NSError-bound, it should at least indicate to consumers of a public API what values can be thrown by a function that throws. Currently, if you don’t have access to the source code for such a function, you have to rely on guess-and-check or documentation to discover what might be thrown. I’m sure Apple is aware of this drawback and have plans for it, but hey — this is my wishlist.