<html><body><p><tt>My personal opinions, as someone who is relatively new to Swift and libdispatch, but has spent some time playing with them recently ;)</tt><br><br><tt>> * What is your evaluation of the proposal?</tt><br><br><tt>Overall, I like the direction of the proposal. I think moving away from the legacy C APIs will make libdispatch in Swift more accessible and pleasant to use.</tt><br><br><tt>I would like to see more details on how the overlay will be implemented on platforms without Objective-C. Specifically, since libdispatch is mostly a C library, it seems to me that this would be a good opportunity to purge Objective-C from the libdispatch implementation entirely and have a simpler and more portable Swift + C implementation. That is what we have to do for Linux, so let's eliminate some of the platform differences and do it everywhere. However, that may be at odds with the "without adding runtime overhead" objective of the proposal. I made an attempt earlier this spring to get libdispatch's C structs to masquerade as Swift classes (instead of Objective-C classes as they currently do when Objective-C is available). I gave up because some of the implementation tricks used in libdispatch's queues made it a fairly invasive change. However, others more skilled in Swift+libdispatch might be able to pull it off. Is the implementation plan to write a fairly thick Swift layer that wraps primitive C types, or is it something else?</tt><br><br><tt>Echoing others, I would keep sync/async as names in the APIs. These are well known terms that are used in many similar tasking libraries in other languages; they are also familiar to current libdispatch users.</tt><br><br><tt>I would like to see a statically checkable distinction in the API between Darwin-specific functionality and the APIs that are truly cross platform. This mainly shows up in the DispatchSources portion of the API. Tag methods of DispatchSource with availability macros or similar?</tt><br><br><tt>It seems overly verbose to prefix all the types with Dispatch....is this really necessary?</tt><br><br><br><tt>> * Is the problem being addressed significant enough to warrant a change to Swift?</tt><br><br><tt>From a Linux perspective, the existing Swift libdispatch API is badly incomplete. The lack of Objective-C on Linux results in a poor quality import of the dispatch headers. Something needs to be done in the Swift 3 time frame to fix this. We could get by with a less sweeping change than this proposal, but something does need to be done. </tt><br><br><tt>Ideally, the new overlay would also be back-ported to Swift 2.2 to address Drew's valid concerns about maintaining cross-platform code that uses libdispatch during the transition from Swift 2.2 to Swift 3. </tt><br><tt><br>> * Does this proposal fit well with the feel and direction of Swift?</tt><br><br><tt> Yes (but I am newish to Swift...).</tt><br><tt><br>> * If you have used other languages or libraries with a similar <br>> feature, how do you feel that this proposal compares to those?</tt><br><br><tt> It should get libdispatch in Swift to be roughly on par with the integrated experience one gets from using tasking libraries in other modern object-oriented languages with closures. </tt><br><tt><br>> * How much effort did you put into your review? A glance, a quick<br>> reading, or an in-depth study?</tt><br><br><tt> Read proposal carefully. Have thought about the issues quite a bit recently. </tt><br><tt><br>--dave</tt><br><BR>
</body></html>