As expected with the holiday season, things are slowing down for a bit on Swift.org. I have been traveling for the holidays as well, so this issue will be shorter than usual. If you haven’t already, be sure you take some time away from coding to enjoy the holidays and avoid burnout. Now, the weekly brief!
Commits and pull requests
@masters3d merged a pull request to swift-evolution that documents commonly proposed changes to Swift. This is a great idea to help reduce duplicate proposals. Don’t forget to check this list before suggesting a change on the mailing list!
Doug Gregor implemented SE-0001, which “allows (most) keywords as argument labels”. This is a great change. When Swift was initially released, one of my Objective-C libraries used
extension: as a parameter name (for a file extension string) and bridging to Swift caused all kinds of problems, thus I ended up having to rename it to
fileExtension:. Glad to see I can revert this change in Swift 2.2! Note that the keywords
inout are excluded from this.
Kevin Ballard’s proposal (SE-0015), Tuple comparison operators has also been accepted! As of this writing, the status of the proposal on GitHub has not been updated to reflect this. Since this proposal should not affect existing code, I assume it will be included for Swift 2.2.
Joe Groff submitted a proposal to add property behaviors to Swift. You can find draft on GitHub. Or if you prefer to receive information via tweet, there’s that too. In short, the proposal outlines an extensible framework for applying various behaviors to properties, similar to
copy in Objective-C. Currently, Swift has some special-purpose hardcoded behaviors, for example,
didSet. This proposal aims to generalize and unify these concepts such that they are implemented via the same underlying framework and can be easily extended. Clients could even implement their own behaviors. It sounds awesome. Some example behaviors include: lazy, memoization, delayed initialization, resettable, and synchronized. Definitely worth the read!
Andyy Hope started a discussion around adding an
.allValues static variable to enums, which would return an array of all cases in the enum. Looks like there is a lot of support for the idea so far. Jacob Bandes-Storch also brought up this idea up a couple of weeks ago. I would definitely be in favor of this, as I’ve found myself writing this boilerplate multiple times.
Kevin Ballard suggests a more formal “This Week In Swift” newsletter. Maybe I should go ahead and setup swiftweekly.org?
That’s it for this week! Cheers.