Issue #144 26 Sep 2019
Written by: Bas Broek
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.
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-11511 [Compiler] A returning
Array<Void>should give a warning, like
News and community
Proposals in 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.
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.
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.
Just cruising the C++ algorithm list and wondered about
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?
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.)