Issue #26 09 Jun 2016
Written by: Jesse Squires
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!
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).”
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.
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.
letconditions should each specify a single declaration, comma should remain the condition separator, and the
wherekeyword 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:
and though it breaks commonality between
letdeclarations, it’s more important to preserve higher-level consistency throughout the language in how components of expressions and statements are separated.
Proposals in review
Stringtype 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.
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.
And finally — prog rock or computer science? 😂