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

[Zach Waldowski]

I don't recall seeing this proposal being pitched, and will also include
feedback of that stripe. Other responses inline.

On Wed, May 11, 2016, at 12:39 AM, Chris Lattner via swift-evolution
wrote:
> 	* What is your evaluation of the proposal?

Strong +1 in concept. I'm thrilled that this might happen.

+0 in current implementation. The proposal as written does not fully
conform to Swift API standards and does not fully address the current
surface area of the Dispatch API. I am concerned about losing features
and performance in our haste to make something "more Swifty."

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

GCD's lack of integration with Swift — in part from the contusions the
API performs to be compatible with multiple languages at the API level

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

See other feedback below. Making changes in general is very much a good
idea. The APIs described do not always fit with Swift.

Separate from the APIs described herein, I am curious as to how much of
what needs to be done can or should be accomplished with apinotes and
the auditing facilities from SE-0044; it seems like 

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

With additions, the resulting API would be a nice improvement and go a
long way to making Swift feel like it has high-level multithreading
support.

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

In-depth study. I am an aggressive user of GCD in Swift.

---

## Type Naming and Structures

The namespace of GCD is already "Dispatch". The existing types in the
proposal are translating from snake-case to camel-case; this isn't
wholly necessary to me as Swift doesn't suffer from C's global
namespace.

dispatch_object_t is obviously a problem in this respect, but its use is
already fuzzy in current GCD (incl. in other languages; its use in C is
equally sketchy). I almost feel like the features of dispatch_object_t
should be encapsulated in protocols. (resume, cancel, etc.)

## Missing API

- Group, IO, and Semaphore are missing in their entirety.
- Data needs init() to match the dispatch_data_empty constant.
- There's no equivalent to dispatch_data_copy_region(3), which can be
used to step through the contiguous buffers (among other things).
- The shared functionality of dispatch_get_context(1),
dispatch_set_context(2), and dispatch_set_finalizer_f(2) are not
modeled.
- The shared functionality of dispatch_suspend(2) and dispatch_resume(2)
are not modeled.
- Queue has no getters for its label and QoS class.
- Queues do not have any modeling for their target queue.
- Custom queues cannot be created.
- dispatch_barrier_sync(2) is not represented. (Neither is
dispatch_barrier_async(2), but this is modeled by
DispatchWorkItemFlags.)
- No equivalents for dispatch_apply(3), dispatch_main(),
dispatch_after(3).

## API comments

- WorkItem
   * DispatchQueue.asynchronously(_:qos:flags:work:) should have a
   variant that takes a DispatchWorkItem. With the API as written, you
   could not enqueue a work item then cancel it.
   * Flags should be a nested type.

- Source
   * The details section needs examples of at least one of the
   DispatchSource protocols (i.e., DispatchSourceFileSystemObject). The
   current approach would seem to lose API inherited from DispatchSource
   and DispatchObject unless those are modeled in some other way.
   * None of Source's APIs for assigning handlers, configuring timers,
   getting or merging the user-defined data, or cancelling are exposed.

- Data
   * Overall, the API does not encapsulate dispatch_data_t's status as a
   tree of discontiguous buffers. I'd expect at least to have API to
   have a view of the contiguous buffers, for instance.
   * The alternate forms of append(_:) don't address management of the
   appended buffer's memory. Do they copy?
   * What are the COW semantics? In-place mutation is not thread-safe,
   whereas dispatch_data_t's current concatenation mechanisms are.
   * enumerateBytes(_:) is unclear, as it is enumerating the underlying
   byte buffers.

- Queue
   * Queue.asynchronously(group:qos:flags:work:) and
   Queue.synchronously(_:) does not conform to the API guidelines.
   * Queue.synchronously(_:) should be @noescape. If possible,
   rethrowing and returning a <T> would be optimal.

Sincerely,
  Zachary Waldowski
  zach at waldowski.me