Issue #140 08 Aug 2019
Written by: Bas Broek
Podcast episodes to listen to, interesting proposals and tools that help you go through all Swift packages. And more.
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-11198 [Compiler] Compiler crash on
inout-to-pointer used with
@autoclosureparam returning optional
- SR-11261 [Compiler] Parser recovery for keyword after
News and community
Commits and pull requests
The proposal was positively received as addressing a common need for which a standard protocol is appropriate.
During review, there were some concerns about the use of the property
id, with some preferring
identifierto avoid clashes with existing properties, while others stated they would have the same problem with
id. The core team feels that id, as the term of art, is the better choice. Future language features should provide a path to resolve clashes.
Proposals in review
This proposal suggests a new initializer for
Stringthat provides access to a String’s uninitialized storage buffer.
Stringtoday 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
String, which currently uses standard library internals to get good performance when using
CFStringGetBytes. Another, also from the standard library, is
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.
A transformation of the shape, one that returns nothing, is not uncommon in our day-to-day tasks, and in my opinion deserves a name which clearly and conspicuously translates the writer’s intent in call-site.
In this respect, another Container type in Swift that has been added a dedicated method to handle such “transformations” is the Array type. Consider the following functions:
While we would all agree that
forEach(_:)is not a necessity, we can also agree that for the task of printing all elements in an array, this:
reads much nicer than this:
Thus I propose adding a parallel function to
forEach(_:), taking advantage of a similar naming for convenience:
From a perspective of a framework writer it is important to provide clear and understandable documentation for the correct usage of their APIs. Swift allows us to write functions that are at some extent self documenting, and clearly define what the function will actually do.
This draft introduces support for binary dependencies in SwiftPM. It will allow vendors to upload artifacts for all supported platforms which will be resolved, downloaded and linked by SwiftPM. There are still some open things left, which can be found at the bottom, but we wanted to get community feedback before we continue with this.