[swift-evolution] Making asynchronous operations first-class citizens in Swift

[Dan Stenmark]

> 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.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/16749595/attachment.html>