Welcome to issue #26! This week was pretty light. Activity is somewhat winding down, presumably in preparation for WWDC next week. I’ll be skipping the issue next week during the conference and will resume the week after. Hope to see you there!

Also, I forgot to mention last week that it was Swift’s 2nd birthday! (And it’s rude to force-unwrap Swift on its birthday. 😂)

Commits and pull requests

The Swift 3.0 Preview 1 milestone has grown to 98 (closed) issues. We’re still waiting on the first official Swift 3.0 preview. My guess is that this will be announced at WWDC. 😉

@karwa added a -toolchain option to swiftc. “This works like clang/gcc’s -B flag (which allows specifying an alternate toolchain location).”

Chris Williams implemented proposal SE-0093: Adding a public base property to slices.

Erik Eckstein optimized the mangling of specialized generic functions.

Robert Widmann implemented a Clang-like warning if source control conflict markers are detected during lexing.

Accepted proposals

Erica Sadun’s and Chris Lattner’s proposal, SE-0099: Restructuring Condition Clauses, has been accepted with revision for Swift 3.

There was near unanimous agreement that the Swift 2 grammar was inconsistent and ambiguous and should be changed; most of the disagreement centered on how. Many alternatives were discussed, […]

Of these alternatives, the core team found the last one to be the best choice. case and let conditions should each specify a single declaration, comma should remain the condition separator, and the where keyword can be retired from its purpose as a boolean condition introducer. Some code becomes more verbose, but in common formatting patterns, it aligns more nicely, as in:

   guard
     let x = foo(),
     let y = bar(),
     let z = bas(),
     x == y || y == z else {
   }

and though it breaks commonality between let conditions and let declarations, it’s more important to preserve higher-level consistency throughout the language in how components of expressions and statements are separated.

Proposals in review

Austin Zheng’s and Becca Royal-Gordon’s proposal, SE-0089: Renaming String.init<T>(_: T), is under review once again, after having been returned for revision.

Swift’s String type ships with a large number of initializers that take one unlabeled argument. One of these initializers, defined as init<T>(_: T), is used to create a string containing the textual representation of an object. It is very easy to write code which accidentally invokes this initializer by accident, when one of the other synonymous initializers was desired. Such code will compile without warnings and can be very difficult to detect.

Mailing lists

Not from the Swift mailing lists but LLVM, Renato Golin discussed moving LLVM to GitHub. Chris Lattner supported the idea. While not directly related to daily Swift development since mechanisms are in place to sync swift-llvm with upstream, I imagine this could have a huge impact on contributions to LLVM.

Finally

And finally — prog rock or computer science? 😂