In other news, there’s a potentially highly anticipated proposal in review, namely one that introduces a
Result type to the Standard Library. 😱
… so go ahead and read all about this and more exciting progress on Swift.
The top mobile companies like Lyft, Reddit, and PayPal rely on Instabug to iterate faster and enhance their app quality. Instabug’s lightweight SDK lets you receive detailed bug reports directly from testers and users. A screenshot is attached automatically along with screen recordings, device details and repro-steps with each report. Instabug takes just one line of code to integrate the SDK.
Get 20% off for 3 months when you signup and subscribe to any plan. Enter offer code InstabugLovesSwiftWeekly
- SR-9201 [Compiler] Incorrect error message when using optional chaining
- SR-9216 [Compiler] Don’t honor SDKROOT in interpreter mode
Jesse and JP discussed Opaque Result Types, as pitched by Doug Gregor on the forums.
News and community
SwiftNIO is now available as a CocoaPod!
Commits and pull requests
This proposal introduces a weakening of the existing
AdditiveArithmetic, which defines additive arithmetic operators and a zero, making conforming types roughly correspond to the mathematic notion of an additive group. This makes it possible for vector types to share additive arithmetic operators with scalar types, which enables generic algorithms over
AdditiveArithmeticto apply to both scalars and vectors.
Feedback on the proposal was light but all positive, and the proposal was accepted without modifications. The core team discussed moving the unary + member, but ended up agreeing with the proposal as written.
The proposal and implementation have been updated.
To summarize how the proposal has changed:
- The primary working types are now spelled like
Vector3<T>instead of the earlier
- Initializers from any
Sequencewith the right element type are now provided.
- All mask operations are
counthas been renamed
- The general swizzle / shuffle / permute operation
init(gathering: at:)has been removed. We intend to restore it in a later proposal with a better name.
- Users can make
VectorN<T>available for arbitrary types
Tto a new
SIMDVectorizableprotocol, which has very basic requirements.
- The any and all and
clampfree functions have been removed. We intend to re-introduce this functionality (possibly with different bindings) in a follow-on proposal.
FloatingPointVectorprotocols have been removed and replaced with conditional conformances.
Although the core team agrees that iterating through collections wrapped in
Optionalis a common enough occurrence to be worth providing affordances in the language for, it has decided to reject the proposal as written.
I’d encourage to read the full rationale.
Proposals in review
Swift’s current error-handling, using
catch, offers automatic and synchronous handling of errors through explicit syntax and runtime behavior. However, it lacks the flexibility needed to cover all error propagation and handling in the language.
Resultis a type commonly used for manual propagation and handling of errors in other languages and within the Swift community. Therefore this proposal seeks to add such a type to the Swift standard library.
This is a proposal for adding support for specifying a per-platform minimum required deployment target in the
Packages should be able to declare the minimum required platform deployment target version. SwiftPM currently uses a hardcoded value for the macOS deployment target. This creates friction for packages which want to use APIs that were introduced after the hardcoded deployment target version.
Michael Ilseman shared String’s proposed Application Binary Interface (ABI) and that native Swift strings will be stored as UTF-8!
We just landed String’s proposed final ABI on master. This ABI includes some significant changes, the primary one being that native Swift strings are stored as UTF-8 where they were previously stored either as ASCII or UTF-16 depending on their contents.
NSStrings are still lazily bridged in to String without copying.
This does not immediately surface in the API, but allows for some important performance wins and gives a more consistent basis for future APIs providing efficient and direct access to the underlying code units. UTF-8 is a one-byte Unicode encoding and is the preferred encoding for interoperating with C, systems programming, server-side programming, scripting, client-side programming, and tools that process source code and textual formats.
With this change, the Standard Library’s binary is around 13% smaller as well!
Vapor is splitting out two new libraries from its core library.
We’re starting work on two new packages that will debut with Vapor 4. NIOKit and CodableKit. The goal of these packages is to break out a lot of utilities Vapor has developed over the past two years in our Core 1 repo. This repo has grown quite large and contains a lot of things we think would be useful to the Server community as a whole, not tied to Vapor.
As I’m sure you are aware, the first Swift 5 branches will be cut soon and needless to say SwiftNIO wants to be able to make full use of the new features/improvements upcoming in Swift 5 (for example native UTF8
Strings). On top that, SwiftNIO already accumulated a number of issues/[pull requests] that can only be addressed with a new major SwiftNIO 2.0.0 release.
Our plan is to therefore release SwiftNIO 2.0 together with Swift 5.0. NIO 2 will require Swift 5 and will be a breaking release. Don’t expect everything to break when you need to migrate from NIO 1 to NIO 2 but there will be likely a number of things that can hopefully be fixed mostly through search & replace. We will maintain a list of changes with strategies to resolve this.