Is SE-0088 (Modernize libdispatch for Swift 3 naming conventions) open for comments?


(Josh Osborne) #1

I see the active review dates of May 10 to 17, but I don’t see any messages about it on here.

If comments are welcome at this time, read on. If not, please remind me what the process is (and maybe read on anyway?)!

Interoperation:
  If I have an existing ObjC (or just C) code baae that uses dispatch_get_specific, how does it interoperate with Swift code and DispatchSpecificKey<T>? How do I annotate my void* keys to bridge them into Swift? (I don’t know of any library that used dispatch keys in API, but I do know of plenty that use them internally and it would hinder Swift migration to have an all-or-nothing migration here!)

Apparently Incomplete (perfectly understandable if I’m jumping the gun and commenting early):

DispatchGroup:
  I can see it has been renamed, and what the equivalent of dispatch_group_async is, but I don’t see dispatch_group_wait or dispatch_group_notify’s new names anywhere.

DispatchSemaphore:
  Again I see the new name, but I don’t see

Bikeshed:
  queue.asynchronously(…) oh dear god so much typing…um, I mean, er, “async is a term of art, and perfectly appropriate here”
  queue.synchronously(…) yeah, that is a lot of letters…and “sync” is a perfectly fine term of art, can we use it?

Color Me Impressed:
  “ all without adding runtime overhead” and we have the DispatchQueue.asynchronously taking 3 arguments with default values. Can the Swift compiler really turn a call with all the arguments in the default state into a dispatch_async call without runtime overhead of checking for nil/.unspecified, and []? (not “can” = “sure, someday”, but “yeah, it does that sort of thing, maybe even here”)