[swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[David P Grove]

My personal opinions, as someone who is relatively new to Swift and
libdispatch, but has spent some time playing with them recently ;)

>    * What is your evaluation of the proposal?

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.

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?

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.

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?

It seems overly verbose to prefix all the types with Dispatch....is this
really necessary?


>    * Is the problem being addressed significant enough to warrant a
change to Swift?

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

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.

>    * Does this proposal fit well with the feel and direction of Swift?

	Yes (but I am newish to Swift...).

>    * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?

	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.

>    * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?

	Read proposal carefully.  Have thought about the issues quite a bit
recently.

--dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/815d237a/attachment.html>