Full steam ahead: with Swift 5.1 released and the release process for Swift 5.2 outlined, we can look forward to another wave of improvements to the Swift language coming up.
有兴趣赞助 Swift Weekly Brief？点击这里
Starter task
- SR-11511 [Compiler] A returning
value of
Array<Void>should give a warning, likeOptional<Void>
Podcasts
Jesse and JP discussed the Swift 5.1 release with Doug Gregor.
News and community
Ted Kremenek wrote a blog post describing the Swift 5.1 release and all of its changes.
Nicole Jacque shared the Swift 5.2 release process, “a release meant to include significant quality and performance enhancements.”
Adam Fish announced iOS bitcode support for Rust.
Victor Guerra shared a talk about using Swift as syntactic sugar for Multi-Level Intermediate Representation in Swift for TensorFlow.
In other Swift for TensorFlow news, Brad Larson announced the release of Swift for TensorFlow 0.5.
Mishal Shah announced Swift 5.1 availability on Docker.
Derik Ramirez shared a blog post
on building a server-client application using Network.framework.
Proposals in review
SE-0264: Standard Library Preview Package is under review.
We propose the addition of a new package,
SwiftPreview, which will form the initial landing spot for certain additions to the Swift standard library.Adding this package serves the goal of allowing for rapid adoption of new standard library features, enabling sooner real-world feedback, and allowing for an initial period of time where that feedback can lead to source- and ABI-breaking changes if needed.
As a secondary benefit, it will reduce technical challenges for new community members implementing new features in the standard library.
In the first iteration, this package will take the following:
- free functions and methods, subscripts, and computed properties via extensions, that do not require access to the internal implementation of standard library types and that could reasonably be emitted into the client
- new types (for example, a sorted dictionary, or useful property wrapper implementations)
- new protocols, with conformance of existing library types to those protocols as appropriate
The package will not include features that need to be matched with language changes, nor functions that cannot practically be implemented without access to existing type internals or other non-public features such as LLVM builtins.
Swift Forums
Xi Ge pitched a compiler proposal to emit source information during compilation.
To enhance the user experience of diagnostics on locally built modules, we propose emitting an additional file during compilation to keep track of the source locations of decls (
.sourceinfofile). Mapping from decl USRs to source locations in the local file system, the file is always emitted as a side product of Swift modules into a private sub-directory (swiftmodule/private). This ‘private’ sub-directory will be present in a local build but excluded for packaging a Swift module for client consumption. A source location is encoded as an absolute path to the source file and the byte offset inside the source file.
James H asked about Swift’s performance on the server.
I want to know if there are any plans to effort improving Swift’s performance? Benchmark after benchmark have…pretty dismal… metrics for Swift when compared to other systems languages.
Now you could make an argument that benchmarks aren’t necessarily representative of real-world use-cases.
The current Swift implementation is still nowhere near representative of the performance that should be possible, since we’ve been primarily in the “make it work” phase of development, and are only now starting to get into the “make it fast” work.
Daryle Walker pitched a proposal to allow for partial sorting in Swift.
Just cruising the C++ algorithm list and wondered about
std::partial_sortandstd::nth_element.But I’m still wondering why would these be needed, outside of implementing other sorting things? Stopping at a point much smaller then the whole collection doesn’t help too much because you still have to scan the whole thing.
Can any of these be implemented stably?
Elviro Rocca asked for an update on modify and yield.
The idea of an
@Atomicwrapper is also cited as an example in the proposal, so I thought it could be implemented, but it seems that you can’t actually do that because you cannot ensure that read-write-read processes actually happen atomically
[..] atomic anything will require compiler support when not explicitly working with pointers or global stored properties. Even with
modify, Swift’s formal model is still move-in/move-out with assumed/enforced exclusivity, not by-address. (modifygets it to move-in/move-out rather than copy-in/copy-out, but not all the way to by-address. That’s still considered an optimization.)