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

[plx]

> 	* What is your evaluation of the proposal?

+1 conceptually, some quibbles.

I agree with a few others that `synchronously` and `asynchronously` aren’t ideal; `dispatchSynchronously` or `dispatchSync` (or `performSync` or `performSynchronously`) all seem more-appropriate.

I understand the impetus behind having fewer core methods, but IMHO the `dispatch_barrier_sync` and `dispatch_barrier_async` calls ought to have direct equivalents here (even if they are just sodlib-supplied conveniences that call through to the unified method).

I also don’t see `dispatch_apply` here anywhere; intentional? Ideally it’d be @noescape, but handling `throw` / `rethrow` for that function in this case seems complicated.

This next one is subjective, but I find the placement of the group-related methods somewhat backwards vis-a-vis how I think of them in terms of the C-API.

EG: I think of `dispatch_group_async` as a “method” on a `dispatch_group`, so would’ve expected this:

class DispatchGroup : DispatchObject {

  // (actual name should match chosen name convention)
  func asynchronouslyDispatch(to queue: DispatchQueue, work: @convention(block) () -> Void)

  // (actual name should match chosen name convention)
  func notify(on queue: DispatchQueue, using block: @convention(block) () -> Void)

}

…(and presumably the API would have manual enter/leave/wait methods and so on exposed).

I don’t feel strongly here but bring it up in case others feel similarly.

I’m a little confused about the `DispatchSpecificKey<T>` class; is it anything more than a way to "smuggle in” a generic type parameter for the associated value? 

Also on queue-specifics, what is our expected story if we have custom destructors? Subclass `DispatchSpecificKey`? 

For things like `Int` specifics, I assume this API is storing auto-boxed values…? Is there any way to side-step if we use want to store an unsafe pointer? It’s not a big deal for me if we can’t under this API, TBH, but I’d at least like to see this API’s implementation and costs spelled-out more explicitly.

For `DispatchData`, is there a principled reason there isn’t something like this defined:

struct DispatchDataSegment {
  let bytes: UnsafeBufferPointer<UInt8>
  let byteIndex: Int
}

extension DispatchData {

  /// Returns a sequence that enumerates the contiguous chunks,
  /// e.g. a sequence with elements of type `DispatchDataSegment`.
  ///
  /// Sequence-based eplacement-for `enumerateBytes(_:)`
  var segmentSequence: DispatchDataSegmentSequence { get }

}

…or something analogous (instead of the proposed use dispatch_data_apply?)? 

I don’t see any API yet for setting target queues, or getting queue labels. I know the proposal isn’t documenting the APIs in full but it’s hard to evaluate in that absence.

I don’t see basic API on dispatch sources yet for things like setting event handlers, (etc.); again I know the APIs aren’t fully specified here but it’s hard to evaluate something that’s not fully specified.


> 	* Is the problem being addressed significant enough to warrant a change to Swift?
> 	* Does this proposal fit well with the feel and direction of Swift?
> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution