Issue #154 27 Feb 2020
Written by: Bas Broek
I’ve been keeping myself busy the last two weeks with exciting things going on at work, and visiting other offices. We’ve also been hard at work on preparations for the SwiftAveiro conference, which I’m co-organizing this year.
All in all, cool stuff going on!
That said, here’s what kept some other people busy these past two weeks…
Hey 👋 We are building a Mac app which is 💯 Swift and AppKit
1. View downloads and sales on the same page
2. Edit metadata for multiple languages in batches
3. Manage customer reviews and developer responses
4. All fetched data is stored locally and never leaves your Mac
5. Customers love it ❤️
- SR-12247 [Compiler] Replace the
ModuleDecl::ImportedModulewith a dedicated struct
- SR-12248 [TypeChecker]
<unknown>diagnostic location regarding
News and community
Commits and pull requests
Max Desiatov merged a pull request, upstreaming almost a quarter of the huge patch from the SwiftWasm team, which brings us closer to enabling WebAssembly/WASI target in the compiler and running Swift code in browsers.
The review has concluded and the proposal is accepted.
The second review has concluded and the proposal has been accepted.
#filewill be altered to only report the module and filename
#filePathwill be introduced to replicate the previous full file+path for use cases that relied on the path previously.
- While the team acknowledges that this does require some existing workflows to adapt to the new scheme, the binary size and privacy concerns over implicitly embedding the full path were significant enough to warrant this change.
During the second review, the format of the new
#filevalue was discussed and will be locked down in a way that users can rely on. The core team expects future tooling to be created that will allow for easy processing of this value.
Proposals in review
This proposal builds on top of the Package Manager Resources proposal to allow defining localized versions of resources in the SwiftPM manifest and have them automatically accessible at runtime using the same APIs.
The recently accepted Package Manager Resources proposal allows SwiftPM users to define resources (images, data file, etc…) in their manifests and have them packaged inside a bundle to be accessible at runtime using the Foundation
BundleAPIs. Bundles support storing different versions of resources for different localizations and can retrieve the version which makes most sense depending on the runtime environment, but SwiftPM currently offers no way to define those localized variants.
While it is technically possible to benefit from localization today by setting up a resource directory structure that the
BundleAPI expects and specifying it with a
.copyrule in the manifest (to have SwiftPM retain the structure), this comes at a cost: it bypasses any platform-custom processing that comes with
.process, and doesn’t allow SwiftPM to provide diagnostics when localized resources are mis-configured.
Without a way to define localized resources, package authors are missing out on powerful Foundation APIs to have their applications, libraries and tools adapt to different regions and languages.
I am extremely excited to announce that as of today we have the full test suite for Foundation passing on Windows as well! Although there are a few tests which are testing Unix specific behaviors which do not port, this is largely on parity with the Linux test suite. There are a total of 1706 tests on Windows that are running with Linux currently having 1714.
Now that the swiftwasm project succeeds to pass quite a few tests in its test suite, we are planning to send some patches to upstream.
Before sending them, I want to confirm and clarify the direction of supporting WebAssembly.
I’ve just come up with this crazy idea: what if we allow SPM to build Rust targets?
For now I have the following in mind:
- Obviously, for building Rust targets the rust toolchain has to be installed.
- We don’t use Cargo for building Rust targets, but rather invoke
rustcdirectly. We could allow Swift packages to depend on Cargo packages in the future, but that seems nontrivial.
- Rust targets can only depend on other Rust targets. Swift or Clang targets cannot depend on Rust targets. Why? Because it would require a lot of work. Later we could allow Rust targets to have the “include” directory just like Clang targets, which would contain C headers for that target so that the Rust target could be used from Swift using those headers (just like C++ targets today can be used from Swift via C headers).
It is sometimes desirable for a protocol to require that a conforming type use a property wrapper in the declaration of a required property. This allows consumers of the protocol to access the wrapper’s projected value and properties, not just the wrapped value.
We propose allowing a subset of property wrapper syntax to appear in protocol declarations.
In the Swift 3 era, several source-breaking proposals had been accepted with the goal of cleaning up and regularizing parts of the language. However, many of them have been stuck in the “Accepted” but not “Implemented” stage for quite a while now, because we never quite got , and the barrier for breaking source compatibility is much higher now than it was in the heady early days of Swift evolution. As such, the Core Team has started going through some of these proposals to record their current implementation status and subset out remaining unimplemented source-breaking changes. To start off, I recently reviewed the implementation status of two proposals:
- SE-0110, Distinguish between single-tuple and multiple-argument function types
- SE-0155, Normalize Enum Case Representation
This proposal changed the behavior of functions with multiple arguments from being considered to have one formal argument of tuple type to instead be treated as formally having multiple arguments. This change has been fully implemented as of Swift 5.2; however, the original proposal as reviewed did not include the special-case conversion from
(T, U, ...) -> Vto
((T, U, ...)) -> Vfor function arguments. In response to community feedback, this conversion was added as part of the Core Team’s acceptance of the proposal. If and when that happens, it will be done as a fresh pitch and proposal.
Although unfortunate, the Core Team does not consider it worth breaking source compatibility to change this behavior. Therefore, the pattern matching part of the proposal has been downscoped to allow for disambiguation when multiple cases share a base name, without changing the behavior for existing enums supported today.
- Some packages use dash-case (aka kebab-case). Notable examples:
swift-nio. Other that fall into this group are SSWG packages and the new standard library preview packages.
- Some packages use CamelCase. Notable examples:
SwiftSyntax. Almost all iOS/macOS packages follow this convention.
I understand if this detail is considered trivial or irrelevant, especially since package names play a much lesser role compared to other package managers such as npm. It is also worth noting that this situation is not unique to SPM and can be found in other ecosystems, such as Rust, where
dash-casedcrate names are both widely used (although the latter is gaining more momentum).
At the same time, I think that with the eventual introduction of a package registry (GitHub’s or otherwise), these naming inconsistencies are going to surface to the end user much more than they do today.
Is the absence of SPM package naming guidelines by design? If so, can someone shed some light on this? If it is not, would it make sense to pursue converging towards one convention? Could it happen organically or should it be enforced on the manifest level?