Returned

SE-0018 Flexible Memberwise Initialization proposal returns to Evolution list for further development without acceptance or rejection. It proposed to extend memberwise initialization from structs to classes, to avoid excessive boilerplate code. Reception on the list was mixed about specific implementation details but many devs like the core idea. Apple promises specific feedback soon.

Active Review

SE-0010 proposes to add a non-mutable StaticString.UnicodeScalarView. (I like it). SE-0013 will remove partial application for non-final “super” methods. I’m agnostic on this one and haven’t spent much time looking at it. SE-0020 aims to extend  build configurations to differentiate code based on the current Swift language release. (I like this one too!)

Upcoming

There’s Doug Gregor’s SE-0021, which provides more specific ways to reference possibly overloaded functions within modules and his SE-0022, which creates sensible argument-label-aware selectors vs the current string approach. (+1 for both.)

Accepted

SE-0011 was accepted for Swift 2.2, differentiating typealias implementation from associatedtype requirements in protocols.

Discussed

Every time I think I’m making headway in reading the list, my unread messages count goes back up above 500, and it’s overwhelming. I’m keeping an eye on a few topics that probably aren’t generally of interest to most developers.

There’s also topics right now about evolving sequences and collections, adding more stdlib features from other languages, tweaking protocols, etc.

There were two proposal discussions that I thought were really cool: adding an “entirely uninitialized” alternative to nil called none and adding named invariants for variable declarations. These were greeted…poorly. I encourage you to look them up, both from Amir Michail.

There was conversation on closures with an inferred return values but that seems to have died pretty miserably too. In the current version of Swift, inferred return is limited to one-line closures. It seems you could rule out branching scenarios — it would have to be an unambiguous endpoint — but this was argued over and faded away.

I vaguely remember seeing something about eliminating trailing closures for any multi-closure parameter calls but I can’t seem to track it down now that I’m writing this stuff up. In any case, I approve because doing one branch of success-error as an argument and the other as a trailing closure makes no sense.

What on-list topics caught your eye? Drop a comment or tweet.