Issue #6 21 Jan 2016
Written by: Jesse Squires
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
@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.
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. 😎
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:
Also remember that Swift’s
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.
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
.cases, which returns an array of all cases in the
enum. Currently, we have to write this manually.
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. 👍
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.
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