It has been over a month since the initial Swift open source announcement and I still keep discovering new things. I’m still just as excited to watch Swift grow and evolve. Welcome to issue #6 of the weekly brief!

Commits and pull requests

Anton Blanchard has his pull request merged which adds PowerPC64le Linux support. Impressive and very cool, indeed. 😎

@lplarson submitted a pull request to support code coverage analysis. Glad to see this. It would be great to get automatic reports on pull requests, too.

Chris Lattner continued his late night hobby — fixing more radars.

The curious case of the associatedtype (proposal here): Greg Titus implemented associatedtype. 👏 Then @eeckstein reverted the change due to failing tests. Doug Gregor then reverted the revert with fixed tests. (Yo dawg, I heard you like reverts) Long story short, associatedtype is now implemented for Swift 2.2. 😎

Greg Titus also updated the stdlib for associatedtype. And Luke Howard merged a pull request to update corelibs-foundation. 🎉

Stephen Celis cleaned up NSDateFormatter. This is not necessarily a notable change, but what’s interesting to me is that NSDateFormatter was originally implemented with Objective-C style (now referred to as “old school” style) ivars and public getters/setters. This is precisely the kind of boilerplate that Swift aims to reduce. 😂 Another alarming thing is that the non-public properties were marked as internal rather than private, meaning the entire Foundation module had readwrite access and could bypass the public getters/setters. 🤔 Odd. Here’s an example:

// Before this commit
internal var _dateStyle: NSDateFormatterStyle = .NoStyle
public var dateStyle: NSDateFormatterStyle {
   get {
       return _dateStyle
   }
   set {
       _reset()
       _dateStyle = newValue
   }
}

// After this commit
public var dateStyle: NSDateFormatterStyle = .NoStyle {
    willSet {
        _reset()
    }
}

Also remember that Swift’s willSet/didSet property observers were available since 1.0, which makes this even more bizarre. However, it’s most likely that this was automatically generated from an Objective-C interface. In that case, I’m sure there are plenty of areas that could use improvements. Keep digging!

Ted Kremenek fixed two regressions from Swift 2.1 related to parameter parsing.

Proposals

The main README on swift-evolution has been updated to track already implemented and accepted proposals for Swift 2.2. This is a great way to see high-level progress at a glance. Of course, I’ll keep you up-to-date too. 😉

Jacob Bandes-Storch has prepared a proposal, “Derived Collection of Enum Cases”. This proposal would provide a much needed reflection API for enum. Jacob suggests adding an Array property on enum types, .cases, which returns an array of all cases in the enum. Currently, we have to write this manually.

Doug Gregor’s proposal from last week’s issue, “Referencing the Objective-C selector of a method”, is under review.

Jeff Kelley submitted a proposal, “Import Objective-C constants as Swift enums”. The goal here is to expose groups of Objective-C string constants to Swift as an enum instead. This would apply to other types as well, such as groups of integer constants. 👍

Doug Gregor’s proposal, “Naming Functions with Argument Labels”, has been accepted for Swift 2.2 and 3.0.

Mailing lists

Last week, I missed that John Lin started working on a Chinese translation of Swift.org (here). This week, Ted Kremenek continued the thread noting that Swift.org is a Jekyll site, currently hosted on GitHub in a private repository, and that team is planning to eventually make it open source! 🎉

Also from last week (😁), Matthew Johnson’s “Flexible Memberwise Initialization” proposal has been “rejected”, though it is really more like “deferred until after Swift 3”. As Chris Lattner explains, “the core team really doesn’t want to discuss this right now, given that this is purely a sugar proposal and we need to stay focused on the primary Swift 3 goals.”

Swift currently has no way to specify if subclasses are required to call super for overridden methods. I started a discussion to present some ideas for a solution to this by extending the use of required to class methods other than init. (Technically, it began on Twitter, and Nate Birkholz kindly started the thread on the mailing list.) Matthew Johnson has since pointed out additional deficiencies in this area. Of course, you could always make all your methods be initailizers — problem solved. 😂

Davide Italiano announced that Swift is now functional on FreeBSD.

The second review of the “Swift Testing (Package Manager)” proposal has begun! (Revised proposal here). 🎉

Finally

And finally, in case you missed the fun:

Q: As an Objective-C programmer, I’m not very good at dieting. Why?

A: weak self