Erica Sadun

Where technology meets something or other

Ordovician Swift: Evolutionary Advances

Accepted

SE-0088: Modernize libdispatch for Swift 3 naming conventions is accepted with revisions. “libdispatch on Darwin already presents Objective-C compatible types to allow its objects to participate in automatic reference counting. We propose extending this support to present a design that feels “object-oriented” and inline with Swift 3’s API guidelines, all without adding runtime overhead.”

Under the current 2.2 system, dispatch looks like this:

let queue = dispatch_queue_create("com.test.myqueue", nil)
dispatch_async(queue) { 
   print("Hello World") // etc
}

The new system modernizes the calls to look “Swifty”, eliminate snake case, and provide a user experience that better mirrors the readability and flow of modern Swift.

let queue = DispatchQueue(label: "com.test.myqueue")
queue.asynchronously {
    print("Hello World") // etc
}

Team feedback:

The community and core team are both very positive about this massive improvement to the libdispatch APIs.  Much of the discussion has centered around specific details in the proposal – for example the “.asynchronously” method on DispatchQueue.  This great discussion leads to several requested revisions in the proposal:

  • Rename the DispatchQueue.[a]synchronously methods to “.async” and “.sync”, to follow the term of art.
  • Rename DispatchIO setHighWater, setLowWater –> setLimit(highWater:), setLimit(lowWater:)
  • Rename setTargetQueue(queue:) and DispatchSource.setTimer
  • Rename Semaphore, Group and WorkItem: .wait(timeout:) –> wait() and wait(withTimeout:)
  • Expand source handler methods to take the same arguments as async()
  • Expand DispatchQueue.after to take the same arguments as async() in addition to the when: argument

SE-0081: Move where clause to end of declaration is accepted. Team feedback:

The feedback on this proposal was strongly positive from the community and core team.  Some concerns were raised (e.g. about possible interaction with the future “generalized existentials” feature) but further examination turned up that they were at issue regardless of whether this feature is accepted.

The core team agrees that this syntactic structure allows a more natural and beautiful way to structure complex generic constraints, and that “where” clauses should be considered secondary to the primary signature of the declaration (e.g. func, class, etc) in question.

SE-0075: Adding a Build Configuration Import Test is accepted.  Team feedback:

The community and core team are both very positive about adding this functionality.  It is precedented by the __has_include feature in Clang, and may have applicability allowing “conditionally available” features for SwiftPM modules in the future.  The core team spent a significant amount of time discussing the proper naming for this, and came to agree that “canImport” (as proposed) is the best name for this conditional.

Rejected

SE-0041: Updating Protocol Naming Conventions for Conversions is rejected. Team feedback:

The feedback on the proposal was generally positive about the idea of renaming these protocols, but the specific names in the proposal are not well received, and there is no apparent confluence in the community on better names.  The core team prefers discussion to continue — if/when there is a strong proposal for a better naming approach, we can reconsider renaming these.

Active Reviews

Upcoming Reviews

Awaiting Scheduling

If you enjoy these Swift Evolution updates and want to say thank you, consider picking up a book or two. Swift Documentation Markup teaches you how to use Swift’s documentation system to better annotate your code. Playground Secrets and Power Tips unlocks the power of Xcode’s Swift playgrounds. And if you’re looking to pick up solid, day-to-day Swift skills, look no further than the Swift Developer’s Cookbook. (It’s not exactly a cookbook but the name was chosen long before WWDC 2015, so we kind of got stuck with the title.)

Tweet this Post

One Comment

  • The change to libdispatch is welcome, but it is an example of a change that will make existing documentation, sample code and tutorials nearly useless. Another reason to think that Apple should accumulate all breaking changes to one big update when they are ready and then give developers, content creators and newcomers a break.