Currently DispatchQueue.main returns a DispatchQueue object.
I thought that returning a OS_dispatch_queue_main instead could allow clients to extend the class and add features specific to the main dispatch queue of their iOS apps for example.
One possible use case:
Sorry my meassage wasn't very clear.
Not a new type, although a typealias could be a good idea given that OS_dispatch_queue_main is not a very swifty name.
A type alias would provide a name that's more consistent with other Swift names. That's all.
The important question is whether the declared type of DispatchQueue.main should be changed to OS_dispatch_queue_main.
The C API, dispatch_get_main_queue, returns a dispatch_queue_main_t, which is a typedef for NSObject<OS_dispatch_queue_main>. The Swift refinement, DispatchQueue.main, has type DispatchQueue. The Swift API discards type information that is available in C.
I was just wondering why OS_dispatch_queue_main didn't follow Swift naming conventions and then had this typealias idea.
I don't know what's happening here but it's the only reference to OS_dispatch_queue_main I found:
Let's forget the typealias idea then
What about the return type of DispatchQueue.main? Would it be possible to refine it?
Changing the type would unfortunately be a source-breaking change, since someone might be relying on it to infer the type of a var that later gets set to DispatchQueue.global() or something.
It does seem a little weird that OS_dispatch_queue_main and OS_dispatch_queue_serial exist but weren't refined on the Swift side, but we'd need a Dispatch person in here to talk about if there's a specific reason for that.
Ok thanks.
I thought it would be a harmless change because type(of: DispatchQueue.main) returns a OS_dispatch_queue_main type, but I had not thought about this case.
I'm going to add a static method and call it like this DispatchQueue.mainAsyncIfNeeded { ... } which reads almost as my original example.
The concurrency design (coming in a few weeks, I promise!) will likely demote the importance of using this API directly; I wouldn't put work into refining it.