Issue #199 02 Dec 2021
Written by: Kristaps Grinbergs
Hello all! I truly hope you enjoyed Thanksgiving and were able to spend the holiday with your loved ones. Maybe some of you even played Chandler’s invented game of naming all 50 states in 6 minutes.
The period after Thanksgiving was very productive for the Swift team, and there’s a lot of activity to discuss today. But before we jump into it, I’d like to use this opportunity to say that the next issue will be the last issue for me and maybe for this project. Please let me know if anyone is interested in taking over my duties. I would love to see this project stay alive and thrive after I leave.
Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for iOS devs who want to become complete Senior iOS Developers.
News and community
During the review, there were two main areas of discussion:
- The spelling of optional types. The proposal leaves this as
(some P)?even though
some P?is more succinct and could potentially be allowed as sugar. The core team agrees with this more conservative approach, which could be revisited later after more experience with the feature.
- The use of
somein “consuming” rather than “producing” position when returning function types i.e.
f() -> (some P) -> Void. Discussion of other uses of the
somekeyword is ongoing, and there was concern about potential conflict with those future uses. Since the use of opaque result types in consuming position is not especially useful (such functions are uncallable in all but a few circumstances) the core team has decided to subset out this use, requiring opaque result types only in the return value of returned function types for now.
Proposals in review
SE-0303 introduced the ability to define build tool plugins in SwiftPM, allowing custom tools to be automatically invoked during a build. This proposal extends that plugin support to allow the definition of custom command plugins — plugins that users can invoke directly from the SwiftPM CLI, or from an IDE that supports Swift Packages, in order to perform custom actions on their packages.
SE-0302 introduced the
Sendablerequirements for various language constructs, conformances of various standard library types to
Sendable, and inference rules for non-public types to implicitly conform to
Sendableshows that this formulation is unnecessarily dangerous and has unexpected negative consequences for implicit conformance.
withMemoryRebound(to:capacity:_ body:)executes a closure while temporarily binding a range of memory to a different type than the callee is bound to. We propose to lift some notable limitations of
withMemoryReboundand enable rebinding to a larger set of types, as well as rebinding from raw memory pointers and buffers.
Note this proposal is running concurrently with SE-0334 which also relates to unsafe pointer usability.
This proposal introduces some quality-of-life improvements for
- Add an API to obtain an
UnsafeRawPointerinstance that is advanced to a given alignment from its starting point.
- Add an API to obtain a pointer to a stored property of an aggregate
T, given an
- Add the ability to compare pointers of any two types.
Note this proposal is running concurrently with SE-0333 which also relates to unsafe pointer usability.
This post discusses an enhancement to Swift-DocC and Swift-DocC-Render that will allow developers to build DocC archives that can be hosted without custom routing. This is specifically designed to enable DocC to be used in additional static hosting environments, most notably GitHub Pages.
This change is meant as a quick solution to address a pressing need, and provides general goodness. But please know that we’ve heard the community’s feedback that they would love for Swift-DocC to directly emit static HTML, and this feature is high on the priority list.
I’ve come across factory-type situations where I’ve ended up making a protocol to represent that “this type can be constructed with a default init that takes no arguments”.
I’ve found myself wondering (a) whether this protocol already exists somewhere in the standard library, and (b) whether Swift could auto-conform any type to it if an init() exists for it.
Guillaume Lessard pitched a proposal to make slices of buffers more useful, especially with respect to partial initialization of buffers.
Sub-sequences of the
UnsafeBufferPointerfamily have all the
UnsafeBufferPointer, but have none of their buffer-specific API. This makes partial initialization of a buffer difficult, among other tasks.