Last week in Swift Evolution

Week of Jan 18, 2016

Published on

Here’s a summary of selected updates from last week from the Swift Evolution repo and mailing list:

Under review this week

  • API Design guidelines

    Previously: Week of Jan 11.

    In Swift 3, the look of the language is getting a redesign, which is governed by three interlinked proposals:

    • API Design Guidelines

      The changes proposed in the other two proposals are motivated by these API design guidelines. The guidelines themselves are here: proposed version, in-development version.

      Discussion on the guidelines included these points:

      • There’s a guideline that says:

        When a mutating method is described by a verb, name its non-mutating counterpart according to the “ed/ing” rule, e.g. the non-mutating versions of x.sort() and x.append(y) are x.sorted() and x.appending(y).

        But as Joe Groff pointed out, English is a weird language, so while it works for sort, it doesn’t work as unambiguously for split, cut, etc.

      • As per the guidelines, redundant type names should be removed from function names (like removeElement() becomes remove()), except when the type of the argument doesn’t sufficiently describe what it is (like addObserver(), which should remain as is).

        As per the proposal, the function should continue to be invoked as addObserver(obj, forKeyPath: path). David Owens suggested that invoking it as add(observer: obj, forKeyPath: path) would read better.

      • While we’re here, why should enums remain UpperCamelCase? Like other non-types, shouldn’t they be lowerCamelCase?

    • Objective-C name translation

      These are some of the changes planned for how Obj-C APIs are accessed from Swift 3:

      • Prune redundant type names from function arguments, so it’s remove(member: Element) rather than removeElement(member: Element)
      • Prepend is to Boolean properties, so it’s application.isStatusBarHidden rather than application.statusBarHidden (See all changes like this)
      • Strip the NS prefix from Foundation APIs, so it’s Rect rather than NSRect (See all changes like this)

    • Swift stdlib API changes

      These are some of the changes planned for the Swift Standard Library:

      • Remove Type suffix from protocol names, so it’s Collection, not CollectionType
      • Generators are now called iterators. For example, SequenceType.generate() -> Generator becomes SequenceType.iterator() -> Iterator.
      • Non-mutating methods shouldn’t read as command-verbs. So sort() that currently returns a sorted list becomes sorted().

Accepted proposals

  • Testing for Swift packages

    Previously: Weeks of Dec 28, Jan 4, Jan 11.

    The Swift Package Manager team’s proposal to include tests in Swift packages was accepted.

    This proposal doesn’t support arbitrary test frameworks. Rick Ballard, the review manager, says:

    This initial proposal includes support for using XCTest; we expect that adding generic support for other testing frameworks will be discussed in an upcoming proposal.

  • Naming functions with argument labels

    Previously: Weeks of Dec 28, Jan 11.

    Doug Gregor’s proposal to identify functions with argument labels was accepted. The code would look something like this:

    let someView = UIView()
// Assign function to variable
let fn1 = someView.insertSubview(_:aboveSubview:)
// Call assigned function
fn1(subview1, aboveSubview: subview2)

    Doug Gregor already has a working implementation of this proposal.

Review discussions

  • Referencing Obj-C selectors cleanly

    Previously: Week of Jan 11.

    The syntax originally proposed to refer to Obj-C selectors was Selector(foo:). Last week, the Swift team felt that this particular syntax was hard to implement. Joe Groff says:

    We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed ‘Selector(Type.method)’ syntax. Producing the selector is something that can’t quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector.

    The current favorite alternate syntax for this is #selector(foo:).

Merged proposal implementations

Other weeklies