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

[Brent Royal-Gordon]

> 	* What is your evaluation of the proposal?

I'm overall in favor.

I agree with the others who say that `synchronously` and `asynchronously` are poor name choices. If we're going to deviate from the API guidelines, we should at least choose names which have other desirable properties, like brevity or matching existing terms of art. These names don't. I would prefer `sync` and `async`, or if necessary, `dispatchSync` and `dispatchAsync`.

I'm very impressed by the way the "specific" APIs have been translated to Swift, but I think the method names are wrong, particularly the `get` method. Ideally these would be a subscript, but we don't have generic subscripts yet. Failing that, I suggest using `specificValue(for key:)` and `setSpecificValue(_ value: for key:)`. I'm also worried about how this will interoperate with Objective-C: Will there be some way to smuggle one of the arbitrary Objective-C pointers for this API into Swift as a DispatchSpecificKey, or vice versa?

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

Yes. libdispatch is pretty awkward even in Objective-C, let alone in Swift.

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

Yes.

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

N/A.

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

Quick reading.

-- 
Brent Royal-Gordon
Architechies