Issue #173 19 Nov 2020
Written by: Kristaps Grinbergs
Great news for server-side folks. We have now Swift tooling for Kubernetes. Now you can orchestrate your server containers using language you know and love.
We’re close again to the Holiday season and there is a special schedule when merge access is locked. I think it’s great to take some time and unplug. I know from myself, it is hard to do it, especially if you’re passionate about a project you’re working on.
Raycast pairs macOS Spotlight with deep integrations to your web apps. Create issues in Jira, merge pull requests in GitHub, or join Zoom calls with a few keyboard shortcuts. Extend the app with scripts to automate every-day tasks. Built for macOS with 100% Swift inside.
- SR-13848 [Compiler] Restore Note About Optionality Mismatch in Redeclared Functions Involving IUOs and Optionals.
Commits and pull requests
During the review, several community members requested to learn more about the Package Collection data format. The core team felt the proposal should be amended to explicitly call out if the data format is part of the feature specification or not, and provide reasoning for its inclusion or exclusion.
For example, it makes sense for the data format to be included if it is considered a stable API that users may build tools around, and conversely it makes sense to exclude if it is considered a non-stable API that users should not be generated directly.
Proposals in review
Swift historically supported the
#availablecondition to check if a specific symbol is available for usage, but not the opposite. In this proposal, we’ll present cases where checking for the unavailability of something is necessary, the ugly workaround needed to achieve it today and how a new
#unavailablecondition can fix it.
Swift-evolution thread: Discussion thread topic for that proposal
This is a proposal for adding support for Package Collections to SwiftPM. A package feed is a curated list of packages and associated metadata which makes it easier to discover an existing package for a particular use case. SwiftPM will allow users to subscribe to these collections, search them via the swift package-collections command-line interface, and will make their contents accessible to any clients of libSwiftPM. This proposal is focused on the shape of the command-line interface and the format of configuration data related to package collections.
Downloadable snapshots of the Swift 5.4 release branch will be posted regularly as part of continuous integration testing. As support is available, snapshot downloads will be added for newly supported platforms.
Once Swift 5.4 is released, the official final builds will also be posted in addition to the snapshots.
On Dec 14, 2020 the
release/5.4branch will be cut in the swift repository and most related project repositories. This will contain the changes that will be released in Swift 5.4. After the branch is cut, changes can be landed on the branch via pull request if they meet the criteria for the release.
Using static member declarations to provide semantic names for commonly used values is an important tool in API design, reducing type repetition and improving call-site legibility. Currently, when a parameter is generic, there is no effective way to take advantage of these facilities. This proposal aims to relax restrictions on accessing static members via protocol metatypes to afford the same call-site legibility to generic APIs.
You may have seen some posts about WebAssembly support in Swift on these forums previously. These were mostly questions and discussions about the toolchain development. Today I’m excited to make an announcement first and foremost for end users of Swift interested in applying it on more platforms.
Swift on the Server meeting notes:
- Sept 16th, 2020 by Todd Varland
- October 14th, 2020 by Johannes Weiss
- September 30th, 2020 by Tanner Nelson
The Swift Package Manager doesn’t currently provide a way for a package manifest to declare that a target is the main module of an executable. Instead, SwiftPM infers this by looking for a source file named
main.cpp, etc) in the source directory of the target. … The most straightforward approach would be allow a target to be marked as executable in the manifest. This could take the form of either a parameter to the
targettype or a new target type. There is already an established pattern of using the type itself to denote the kind of target being declared (e.g.
testTargetas a specialization of
target), so the most natural approach seems to be to add a new
executableTargettype for this purpose.
Using a separate target type in the manifest would also support any future differences between the parameters for an executable target and a library target.
Dario Rexin informed about static linking on Linux in Swift 5.3.1.
I am happy to announce that with the release of Swift 5.3.1 statically linking the Swift
stdlibcomponents is now fully supported on Linux. This includes linking against Dispatch and the different Foundation components. Additionally building self-contained binaries is now possible by manually adding a few linker flags.
Swift as a language is among the most pleasant to use and it’s seen many advancements in many areas, including the server-side. What’s been lacking, IMHO, is more work put into the whole cloud native landscape, especially Kubernetes.
I hope Swiftkube will contribute towards gapping this bridge.
I just finished landing a set of changes which fix a hole in Swift’s availability checking model. While this was mostly intended for use by Apple, I feel that it is also worth documenting and communicating to the community since people do ship third-party frameworks that make use of OS availability.
As most of you are aware, Swift’s “availability” feature checks if referenced declarations are going to be available at runtime by comparing the OS version in an @available annotation with the “availability context” of the usage location, which is either the deployment target, an @available annotation on an outer declaration, or an if #available block
Thank you for the discussion in the previous pitch thread. I’ve learned a lot from your feedback and made several major revisions to the proposal, notably:
- Simplifying the
ActorSendablerequirement to being a marker protocol, eliminating the possibility of implicit deep copies.
- Including a
ValueSemanticmarker protocol as part of the proposal (but I leave it to Dave and other experts to define exactly what that means).
- Defining away the possibility of “expensive” synthesized cross-actor copies in the face of resilience boundaries and other advanced cases.
Maybe it’s time for a road trip to visit Swift compilers?