Welcome to issue #17! After all this time, the core team is still just as encouraging to contributors as it was on day one. It’s really cool to see this. 😎 Meanwhile, the Swift 2.2.x milestone accumulated more issues, and as of this writing all 33 issues are closed. Maybe we’ll see a patch release for 2.2 soon? Also, yesterday Apple released new betas for iOS 9.3.2, tvOS 9.2.1, watchOS 2.2.1, and OS X 10.11.5 — notably absent is Xcode.

Starter tasks

  • SR-1145: XCTestSuite doc comments describe behavior exclusive to Apple XCTest
  • SR-1141: [llbuild] Add support for understanding Swift parseable output
  • SR-216: Increase test coverage on Linux
  • SR-1111: Non-optimized builds should avoid redundant thick_to_objc_metatype conversions

Suggestions from Brian Gesiak:

  • SR-1124: Migrate legacy Swift stdlib tests to the StdlibUnittest framework. This would make those tests easier to read and maintain. Over the course of completing this task, newcomers to Swift development would become familiar with several tools used to test the compiler. There are 35 tests in total — feel free to claim individual tests by commenting on the task.

Submit a task by sending a pull request or opening an issue.

Commits and pull requests

@swift-ci now knows how to “Please ASAN test”. 😎

Harlan Haskins started work on implementing proposal SE-0046: Establish consistent label behavior across all parameters including first labels. (SR-961) 👍 However, Manav Gabhawala did too. 😳 It looks like everyone is collaborating on Manav’s pull request now. Consider this a friendly reminder to remember to (1) assign JIRA tickets and (2) to check what’s in-progress before starting work on a task. 😄

Anna Zaks merged a pull request that adds experimental support for Thread Sanitizer (TSAN), and fixed a bunch of races it reported. Nice! 🎉

Kevin Lundberg submitted a pull request to corelibs-foundation that adds block and boolean NSPredicates, NSCompoundPredicate, and an implementation of NSArray.filteredArrayUsingPredicate.

Dave Abrahams opened a pull request for the new Set (Algebra) API changes. 🤓

David Grove submitted a pull request to enable the _ObjectiveCBridgeable protocol on Linux, and opened a corresponding pull request on corelibs-foundation that implements basic usage of the _ObjectiveCBridgeable protocol on Linux. 🙌

Jesse Rusak merged an implementation of SE-0037: Clarify interaction between comments & operators, which resolves SR-186 and SR-960.

Ankit Aggarwal merged a pull request on swift-package-manager that adds the ability to auto-generate module map files for C libraries.

Harlan Haskins merged two pull requests to swift-lldb and corelibs-foundation that implement changes specified by proposal SE-0046: Establish consistent label behavior across all parameters including first labels. 👏

Trent Nadeau submitted a pull request that implements part of SE-0047: Defaulting non-Void functions so they warn on unused results (SR-1052) — change the standard library to use @discardableResult on mutating methods that return values.

Ezekiel Pierson merged a fix for SR-1022 which adds an “unused result” warning for #selector.

Nate Cook submitted a pull request that fixes a bug in the LazyFilterCollection index moving functions where they did not trap on advancing past endIndex and in some cases did not terminate at all. 👍

Jordan Rose opened a pull request on corelibs-foundation to update APIs for SE-0055: Make unsafe pointer nullability explicit using Optional.

Accepted proposals

Chris Willmore’s proposal, SE-0054: Abolish ImplicitlyUnwrappedOptional type, has been accepted, pending implementation.

There is generally positive feedback on the proposal, as it keeps the good behaviors of the existing T! type syntax (including support for importing un-nullability-audited APIs, support for 2-phase initialization patterns, etc) while dramatically reducing the confusion and surprise that they introduce as they trickle through type inference. The core team sees significant value in having a simple and predictable model that can be explained concisely.

That said, this is the sort of proposal that can have a profound impact on the actual experience using unaudited APIs. The core team believes that the experience will be good, but we would like to get some experience moving a couple of existing projects (both low-level code that interacts with C, and an “App” project working with high level frameworks) to see what the impact is in practice. If something unexpected comes up, we will revisit this, and potentially reject it later. Chris Willmore is working on an implementation of this now, so we should know in the next week or two.

Of course, another option would be to make Swift 9000x safer with this one small commit. 😂

Jordan Rose’s proposal, SE-0055: Make unsafe pointer nullability explicit using Optional, has been accepted for Swift 3.

The community and core team overall agree that it is best to make the null pointer processing more consistent (by eliminating types that can be nil, but which are not Optional). While UnsafePointer is disliked by many in the community, it is a necessary part of working with C APIs (as one prominent example). Making them work consistently with other types makes the language simpler and more predictable. This approach also dovetails well with the Clang nullability attributes, which allow auditing of C pointers.

Proposals in review

Russ Bishop’s and Doug Gregor’s proposal, SE-0058: Allow Swift types to provide custom Objective-C representations, is under review. This proposal would provide an ObjectiveCBridgeable protocol that allows a Swift type to control how it is represented in Objective-C by converting into and back from an entirely separate @objc type. So far, there are some questions from the community to clarify the proposal, but there’s support for the idea.

Erica Sadun’s and Chris Lattner’s proposal, SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations, is under review. This is another great refinement to the language that will make it more consistent.

Enumeration cases are essentially static not instance type members. Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type. This makes little sense. In no other case can an instance implementation directly access a static member. This proposal introduces a rule that requires leading dots or fully qualified references (EnumType.caseMember) to provide a more consistent developer experience to clearly disambiguate static cases from instance members.

Doug Gregor’s proposal, SE-0057: Importing Objective-C Lightweight Generics, is under review. “Parameterized Objective-C classes lose their type parameters when they are imported into Swift, so uses of type parameters outside of bridged, typed collections (NSArray, NSDictionary, NSSet) don’t benefit in Swift. This proposal introduces a way to import the type parameters of Objective-C classes into Swift.” There hasn’t been much feedback, but it looks like the community mostly agrees that this will enhance bridging between Swift and Objective-C.

Chris Lattner’s proposal, SE-0056: Allow trailing closures in guard conditions, is under review. This proposes exactly what it says, but it’s easiest to explain with an example. The proposal would allow you to do the following, which currently is a syntax error:

guard let object = someSequence.findElement { $0.passesTest() } else {
  return
}

Dave Abrahams’ proposal, SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly, is under review. This proposal is mostly a followup from SE-0006: Apply API Guidelines to the Standard Library, which left the SetAlgebra APIs unadjusted. This proposal establishes the necessary naming conventions and applies the changes to the Set APIs. Naming is always hard and not everyone will agree on what is “best”, but I think we all can agree that Dave and the team have put a tremendous amount of thought and effort into these API naming conventions and guidelines. 🙇

Mailing lists

The discussion on SE-0025: Scoped Access Level has reached a decision regarding the new access level modifier names.

The core team met to discuss this, and settled on the list above: public/internal/fileprivate/private. This preserves the benefit of the “fileprivate” concept that we have today in Swift, while aligning the “private” keyword with common expectations of people coming to Swift. This also makes “private” the “safe default” for cases where you don’t think about which one you want to use, and this schema will cause minimal churn for existing Swift code.

Brian Gesiak started a discussion about SR-710 which tracks a major goal for Swift 3 — having SwiftPM and corelibs-xctest automatically generate a list of test methods to execute.

Here’s the issue: currently, users of corelibs-xctest must manually list each test they wish to execute. This is tedious and error-prone. We need to do better by Swift 3!

Apple XCTest uses Objective-C reflection at runtime to compile a list of NSInvocation to execute as tests. We can’t use the same approach in Swift: as far as I know, there’s no reflection API that allows us to find instance methods defined on a class, and adding such an API is considered a stretch goal for Swift 3.

Brian goes on to explore the different options available and solicit feedback from the core team.

Erica Sadun pitched an idea about adding a Self type name shortcut for static member access to allow using Self as a synonym for an instance’s type name. Consider the following:

struct MyStruct {
    static func foo() { print("foo") }
    func bar() {
        MyStruct.foo() // works
        self.dynamicType.foo() // works
        Self.foo() // error
    }
}

Feedback on the idea has been positive and Erica has drafted a proposal.

Robert Widmann pitched an idea for moving where clauses out of parameter lists to make generic interfaces more readable, inspired by a discussion on Twitter with Erica Sadun and Joe Groff. It looks like the community is pretty supportive of the idea so far. I really hope we get that book, Saduns and Don’ts. 😂

Dave Abrahams started a thread, “My personal beef with leading-dot syntax”. Dave notes a number of reasons why he dislikes the current leading-dot syntax, including that it’s a source of confusion and imposes unnecessary complexity. Joe Groff responded with concerns on the impracticality of “making every unqualified reference context-dependent”, and there’s an interesting back-and-forth between the two of them. Personally, I really like the leading-dot syntax. 😄

Finally

And finally — with all of the recent API transformations, guideline changes, and anticipation for Swift 3, you might be wondering what’s idiomatic Swift look like? “You’re supposed to put radar numbers above everything.” 😂