[swift-evolution] Pitch: Progress Tracking in Swift

[cocoadev at charlessoft.com]

On 2016-01-18 21:12, Rob Mayoff via swift-evolution wrote:
>> 1. Because NSProgress relies on a thread-local global variable to
>> store the current progress object, it is impossible to know, outside
>> of documentation, whether any particular method supports NSProgress
>> or not, and if the documentation is inadequate, one must resort to
>> trial-and-error to determine whether NSProgress is supported (this
>> has been noted before: http://oleb.net/blog/2014/03/nsprogress/
>> [1]).
> 
> iOS 9 and OS X 10.11 support explicit progress composition through the
> addChild:withPendingUnitCount: message, and vending of an NSProgress
> instance (for use with the addChild:withPendingUnitCount: message)
> through the NSProgressReporting protocol. You no longer have to rely
> on implicit composition, and in WWDC 2015 session 232 you're
> encouraged to use explicit composition.

While this is technically true, 1) it is awkward, bloating method 
signatures by requiring you to add a "progress:" parameter to all of 
them, much like the NSError** pointers of old, 2) it doesn't solve the 
performance issues that NSProgress has with all of its KVO notifications 
being sent on the worker thread, and 3) you can't even use it, anyway, 
if you can't require OS X 10.11 or iOS 9.

> I have a hard time believing this is something that needs dedicated
> language syntax.

It's an incredibly common problem; almost every app that spawns a worker 
thread is going to need some way to report progress on the task, and a 
way to cancel it. The more primitive methods are written to support 
progress reporting, the easier it is for larger operations to report 
their own progress effectively, so it makes sense to introduce a 
mechanism that makes progress reporting as easy to implement as 
possible. I think this is what Apple was hoping for with the original 
NSProgress implementation; the implicit composition suggests an 
expectation that all code that does work would support NSProgress, and 
that you could just expect it. Sadly, that hasn't been the case, but by 
giving it first-class language support and making it dead easy to use, 
perhaps we could get closer to that point. At any rate, given Swift's 
focus on performance (and subsequently, the appropriateness of using 
pure Swift in a worker thread), it seems a shame to bog everything down 
with a low-performing progress API like what we have currently.

Charles