So the lovely Greg took over last issue as I was at a conference, try! Swift NYC. I’ve had an amazing time at the conference (and New York) where I gave a talk about the history of Swift. A video of that talk will be posted in the future.
A big thank you goes out to the organizers, the volunteers and all of those who I got to meet at the conference!
We are also working on bringing back subscriptions via email. To cover the associated costs, we are looking for sponsors again.
We’re sharing more details soon. If you or your company are interested in sponsoring the newsletter, please send me a direct message on Twitter.
That being said, and without further ado, here is an update on everything Swift from the past two weeks.
- SR-8625 [Compiler] Swift should warn if a closures is passed to an argument that is an
- SR-8645 [Package Manager] BuildPlan error descriptions aren’t printed
- SR-8646 [Package Manager]
- SR-8671 [Package Manager]
ARG_MAXlimit exceeded when compiles huge project
News and community
Ole Begemann did us all another huge favor by means of a What’s new in Swift 4.2 Playground. You should definitely give this a try if you want a quick and interactive overview of the new features in Swift 4.2.
On a related note, Paul Hudson wrote about what’s new in Swift 5. Besides ABI stability, there are some other interesting new improvements and features expected in that release. Swift 5 is expected to be released early 2019.
Commits and pull requests
Joe Groff merged a pull request that finishes up the implementation of SE-0227 (see below). “Now we’re just waiting for tuple keypaths so we can have full parity between member access syntax and keypath syntax.” 🎉
Feedback on the proposal was light but all positive, and the proposal was accepted without modifications.
Proposals in review
String interpolation is a simple and powerful feature for expressing complex, runtime-created strings, but the current version of the
ExpressibleByStringInterpolationprotocol has been deprecated since Swift 3. We propose a new design which improves its performance, clarity, and efficiency.
We see three general classes of types which might want to conform to
- Simple textual data
- Structured textual data
- Machine-readable code fragments
The current design handles simple textual data, but struggles to support structured textual data and machine-readable code fragments.
As announced at try! Swift New York City, the Swift Server work group is now entering a new chapter in its evolution. With the release of SwiftNIO and it’s subsequent adoption by popular Swift web frameworks, Kitura and Vapor, the group is now ready to take on new tasks. It’s time to focus on defining and creating a set of libraries and tools that are focused on developing and deploying server applications written in Swift.
Read more about the new focus on the updated Swift Server work group page.
[..] the work group came up with the following focus areas which we feel can make a real and immediate impact on the ecosystem. The list reflects what we previously heard from the community as well as our own personal experience writing server applications with Swift, and is designed to solve tangible needs that do not require new features from the language or core libraries.
- Database Drivers and Storage Clients
- Tooling and Production Readiness
- Distributed Systems, Microservices and Event Driven Architecture
A great number of questions are raised in these forums as to the functioning and design of numeric types and protocols in Swift. Sometimes, the answer can be found only by digging through the source code, and even then it’s hard to place what you learn there within a larger context. Therefore, I’ve compiled a series of articles that delve into these topics in more detail.
You can find the blog posts here.
In this pull request, I’m changing code generation for class convenience initializers so that they only have “allocating” entry points, which are responsible for allocating and initializing the entire object. (See Changing class convenience initializers to perform whole object allocation and
@objcinterop for more background.) With this change, convenience initializers are nearly identical to value or protocol extension initializers at the implementation level, since the
self.initdelegation within a convenience initializer is effectively initializing the self reference with a reference to the instance created by the
self.initcall rather than initializing the instance itself. At this point, it’s not that big of a leap to allow the
selfreference to also be initialized by assignment, as it can be in value and protocol extension initializers, like this:
This opens the door to convenience initializers being able to use static factory methods or other
Self-returning operations to produce their returned result, not only the result of other initializers. Swift’s own standard library and Foundation overlay hack around this missing functionality by making classes conform to dummy protocols and using protocol extension initializers where necessary to implement this functionality:
Swift can now even be found in Apple Watch bands. Who would’ve thought?!