[swift-evolution] Pitch: Progress Tracking in Swift

[Félix Cloutier]

In terms of which functions need it, I think that reporting progress is a relatively niche feature. I would by far prefer that we work on infrastructure to implement a library-driven solution. To me, it would be a missed opportunity to show off what the language can (will be able to) do without having to bake it into the compiler.

For instance, this could probably be solved without specific compiler support if Swift had a macro system and resumable functions.

Also, the first two arguments have merit, but it's highly improbable that you'll be able to use whatever solution we come up with in OSes older than OS X 10.11 or iOS 9 anyway.

Félix

> Le 18 janv. 2016 à 21:59:09, Charles Srstka via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160118/3abc09bc/attachment.html>