[swift-evolution] Making asynchronous operations first-class citizens in Swift
daniel.j.stenmark at gmail.com
Wed Dec 9 13:05:00 CST 2015
> The standard library does not really define how errors should be handled in asynchronous scenarios. The throw/catch mechanism obviously doesn't work for asynchronous operations.
> While the compiler checks if a function that returns a value returns one in all possible code paths, the compiler currently doesn't check whether an asynchronous function always 'calls back'. Also, while the compiler prevents you from returning twice from a function, it currently does not prevent you from calling a callback more than once (some callbacks actually are intended to be called more than once of course, but in most cases, but many aren't).
+1. I made a thread earlier about establishing guidelines for asynchronous callbacks, but long term, it would be great to see these promoted to being language constructs. According to the swift-evolution GitHub page, concurrency support is in the works, but is out of scope for Swift 3.0.
> Currently you cannot make any assumptions about the queue/thread on which a callback will be called. This is especially problematic when you want to make UI updates from a callback - all you can do is dispatch_async your updates to the main queue.
I have reservations about this, as I usually see most users (when provided with classes that expose their underlying queue properties) over-abusing the main thread. For the specific issue you’re referencing, I’d rather see that addressed in the UI update model of AppKit/UIKit.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution