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