Welcome to issue #10 of the weekly brief! This week Eddy Cue and Craig Federighi appeared on The Talk Show with John Gruber. There wasn’t much talk about Swift, but they did discuss plenty of interesting things. I highly recommend listening, especially if you are an iOS developer! 📱
Commits and pull requests
William Dillon submitted a pull request that enables
CF_OPTIONS on non-Darwin targets.
Brian Gesiak submitted a pull request to allow corelibs-xctest to be built and tested on Linux and OS X. Finally testing the tests! 😄
Manav Gabhawala implemented the
dataWithJSONObject(_: options:) API in corelibs-foundation.
Doug Gregor fixed rdar://24575507. This bug prevented a type from satisfying a protocol with initializers if an
init() was defined in a protocol extension instead of a concrete class or struct.
Zachary Waldowski’s proposal, Expose code unit initializers on String (SE-0027), is under review. The proposal suggests exposing private
String APIs as public to improve working with byte representations and unicode.
James Campbell’s proposal, Optional Value Setter
??= (SE-0024), is also under review. He suggests adding a new operator,
??=. “If the optional is set via this operator then the new value is only set if there isn’t an already existing value.” Support for this was mixed. Greg Titus didn’t see the value in an extra operator. Ash Furrow noted that he enjoyed having this operator in Ruby. I could go either way here.
Erica Sadun has been on a roll with proposals. 🙇 She contributed a number of small proposals for some really great syntax refinements. Each of these really help bring an overall consistency to Swift.
inoutDeclarations for Type Decoration, co-authored by Joe Groff. This has been accepted for Swift 3. Furthermore, Daniel Duan has already submitted a pull request to implement this! 👏 The main reasons for accepting this include: “(1) The community and core team both widely agree that it makes sense to move the inout keyword into the type position. (2) This reinforces commonality between the declaration and type syntax. (3) This reduces complexity in the Swift 3 language.”
SE-0036 Requiring Leading Dot Prefixes for Enum Instance Member Implementations, co-authored by Chris Lattner. Currently, within an
enumtype you can refer to each case with or without the dot prefix (
.). For example,
first. This proposal aims to always require the
.for a consistent experience.
SE-0034, Disambiguating Line Control Statements from Debugging Identifiers. This is now under review. From the introduction: “The proposal SE-0028 overloads the use of
#lineto mean both an identifier that maps to a calling site’s line number within a file and acts as part of a line control statement. This proposal nominates
#linefor file and line syntactic source control”.
SE-0039 Modernizing Playground Literals. This proposes the following syntax change to playground literals:
- The final proposal is Replacing Equal Signs with Colons For Attribute Arguments. The current syntax is definitely awkward in the larger picture of Swift. It’s easiest to illustrate this with an example:
Joe Groff’s proposal, Limiting
inout capture to
@noescape contexts (SE-0035), is under review. From the introduction: “Swift’s behavior when closures capture
inout parameters and escape their enclosing context is a common source of confusion. We should disallow implicit capture of
inout parameters except in
@noescape closures.” This undesired behavior predates the addition of
@noescape. Dave Abrahams (the original author of the current semantics), Chris Lattner, and Jordan Rose all gave this a +1.
Chris Eidhof noted some subtleties when using the new
associatedtype in Swift 2.2. Good to know! (Not on the mailing lists, but Twitter is close enough, right? 😁)
Evan Maloney started a discussion around introducing a simplified notation to avoid “the weak/strong dance” with closure capture lists. Feedback was pretty mixed, with the most compelling argument against this being that clients should be required to explicitly check for
Dave Abrahams announced that the “InPlace” suffix will be removed from APIs in the standard library, namely SetAlgebra and
Set. This is the result the continuing refinement of implementation of the API Guidelines. (Also, this full thread is huuuge.)
Jordan Rose pitched an idea for overridable members in extensions. “Today, methods introduced in an extension of a class cannot override or be overridden unless the method is (implicitly or explicitly) marked
@objc. This proposal lifts the blanket restriction while still enforcing safety.” So far, there’s positive support for this.
And finally — compiler crashes are fixed pretty swiftly these days. 😎