* 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution