A lot of new hardware to talk and think about from Tuesday’s Apple Event. And a lot of new software to look forward to — which includes a whole lot of the features the Swift team has been working on. I’m very much looking forward to the new software in particular, and the app updates it will bring.

有兴趣赞助 Swift Weekly Brief？点击这里

News and community

The Gradle team announced Swift support to compile, link and install applications and libraries, C++ interoperability, dependency management and more.

Jordan Rose shared a document explaining name translation from C to Swift.

Commits and pull requests

Slava Pestov merged a pull request that directly leads to the elimination of over 400 lines of code from the compiler. 🎉

Johannes Weiss merged a pull request enabling the thread sanitizer for SwiftNIO, now that it works well enough on Linux, thanks to Julian Lettner.

Proposals in review

SE-0263: Add a String Initializer with Access to Uninitialized Storage is under review.

This proposal suggests a new initializer for String that provides access to a String’s uninitialized storage buffer.

String today is well-suited to interoperability with raw memory buffers when a contiguous buffer is already available, such as when dealing with malloced C strings. However, there are quite a few situations where no such buffer is available, requiring a temporary one to be allocated and copied into. One example is bridging NSString to String, which currently uses standard library internals to get good performance when using CFStringGetBytes. Another, also from the standard library, is Int and Float, which currently create temporary stack buffers and do extra copying. We expect libraries like SwiftNIO will also find this useful for dealing with streaming data.

Swift Forums

Davide Mendolia pitched a proposal to introduce generalized Generic Coveriance.

As far as I know, only Arrays support Generic Covariance. Is it possible to generalize it or to introduce in core elements like Result and allow libraries like Combine to use it?

class Base {
}
class Derived: Base {
}

class ArrayBase {
    func foo(x: [Derived]) -> [Base] { return x }
}

Would allow simplification of the following code instead of throwing errors and require casting. Somethings that’s already done today for Optionals and Array.

class JustBase {
    func foo(x: Just<Derived>) -> Just<Base> { return x } // Compiler Error: Cannot convert return expression of type 'Just<Derived>' to return type 'Just<Base>'
}

class ResultBase {
    func foo(x: Result<Derived, Error>) -> Result<Base, Error> { return x } // Compiler Error: Cannot convert return expression of type 'Result<Derived, Error>' to return type 'Result<Base, Error>'
}

Richard Wei shared a proposal for Differentiable Programming.

We have completed a comprehensive proposal for the differentiable programming feature we’ve been incubating over the last 1.5 years. We’ve gone over many iterations on the feature design, and have partially completed the implementation. Now we are ready to start a discussion on Swift Evolution, specifically on upstreaming and standardizing the feature.

Since this proposal is overly long (~60 pages), we hope to start by merging it into the docs/ directory via this pull request, and draft bite-sized proposals that contain references to the mega-proposal.

You can find the full proposal here.

Gwynne Raskind pitched a proposal to support varargs “splat”.

Forwarding variadic arguments has come up fairly often in discussion, and I thought I’d try my hand at working up a proposal, with a focus on arguments against the oft-proposed “prefix operator” syntax.

You can find the full proposal here.

Owen Voorhees pitched a proposal to extend the capabilities of error messages.

As a follow up from Future of Diagnostics UX a couple weeks back, I wanted to further explore the idea of “extended diagnostic messages” and see if they would be a good fit for Swift. What follows is a rough pitch for what that might look like. I’m not sure if this will/should result in an evolution proposal, but I think writing this up using the pitch format makes it easy to evaluate and discuss alternatives.

I’m interested in any and all feedback people have on whether they’d find this useful! I’m especially interested in hearing from anyone who has worked with Rust/Elm in the past and can comment on the benefits & drawbacks of their approaches to diagnostics.

Johannes Weiss shared meeting notes from the Swift on the Server Working Group that took place on August 8.

Finally

I know, I know… Still a good joke in my books.