Issue #163 02 Jul 2020
Written by: Kristaps Grinbergs
This year’s WWDC was a blast. Despite what is currently happening in the world I think Apple created a small “development holiday” for all of us. I think a new online conference reached far more folks around the world than ever before. We got completely revamped developer forums, as well as many community-organized side events that were not tied to any physical location, which is great.
This year we got great new things, especially in SwiftUI, that are driven by new cool additions to the Swift language. And much more. Now we have a full summer to explore new stuff and get ready for new Apple releases and slowly for Apple’s own built silicon.
LINE is the leading mobile messaging platform in Japan and boasts one of the largest Swift codebases in Asia. In addition to supporting Swift versions from day 1, we strongly value semantics, protocols, and strongly typed systems. Many of our members are also active in the OSS community and support both local and global meetups and peer labs. Come join us and see what Swift can do in the real world.
In episode 75 of the Swift by Sundell podcast, Dave Verwer and Sven A. Schmidt join John to talk about their newly launched Swift Package Index, and what the overall state of Swift’s package ecosystem is. Also dependency management, composing libraries, deploying server-side Swift in production, and much more are discussed.
News and community
In this year’s WWDC 2020 Apple had two main sections of videos about the Swift language and relevant topics:
- The TL;DW for Apple’s WWDC videos. You can read session notes written by the community.
Apple released Xcode 12 and here are the release notes of what has changed in Swift.
The first release candidate of Swift for TensorFlow v.0.10.0 is out.
Commits and pull requests
Slava Pestov merged a pull request
that fixes a bug in generic signature minimization. It turned out
that the fix didn’t require a big redesign of the
after all. It’s just a five line addition of a new
Michael Gottesman merged a pull request that adds an option that causes the generic specializer to validate newly specialized functions earlier when there is more information that can be put into a pretty stack trace.
This proposal does not specify whether/how dependency chains arising from the C/C++
memory_order_consumememory ordering work in Swift. The consume ordering as specified in the C/C++ standards is not implemented in any C/C++ compiler, and we join the current version of the C++ standard in encouraging Swift programmers not to use it. We expect to tackle the problem of efficient traversal of concurrent data structures in future proposals. Meanwhile, Swift programmers can start building useful concurrency constructs using relaxed, acquire/release, and sequentially consistent memory orderings imported from C.
Swift’s higher order functions mostly predate the API guidelines and are based on terms of art. The community debated about this in the past and the “Term of Art” hammer won at that time. Perhaps we can reconsider now that Swift is entering its comfortable middle age reflective period as a missed opportunity.
It would be simple to alias
filter, etc with API compliant names (
filtering), slow-walk-deprecate the former with the gentlest touch, and move towards a more consistent dev-facing vocabulary by replacing the terms in the SPL docs and devdoc tutorials (with footnotes or sidebars) to establish a new standard long before removing the old.
Breaking changes have a high bar so it would take such a slow and cautious approach to migrate the community towards these changes. Backwards compatibility would need to be maintained for a longer period of time than usual. I’m curious as to what people think.
A Swift Package defines the sources and dependencies for successful compilation. The
PackageDescriptionspecifies items like the supported Swift version, linker settings, and so forth.
What it does not do is offer metadata. You won’t find email for the active project manager, a list of major authors, descriptive tags, an abstract or discussion of the package, a link to documentation, deprecation information or links to superceding packages upon deprecation.
In light of the discussion of principles for (trailing closure) evolution proposals and based on feedback we’ve received from the Swift 5.3 development snapshots, I’d like to revisit SE-0274: Concise magic file names. In particular, I feel like SE-0247 has violated the “Source Compatibility” principle more than is necessary, and that we should consider revising the proposal.
SE-0247 includes an additive change (
#filePathliteral to provide the full path to the file), but then introduces three changes that affect existing sources:
#fileliterals have a different form that does not include the full path name. Therefore, the spelling
#filehas changed meaning.
- The compiler provides a warning when a wrapper around a
#filePath-defaulting function passes it
#fileinstead, or vice versa.
- Standard library functions like
#file, and therefore have had their behavior changed to no longer produce the full path name by default.
This proposal introduces a syntax for defining funciton-typed variables which have compound names (i.e., names with argument labels). This allows the call sites of such variables to achieve the same clarity that is achieveable with
In many challenges of API Designs, you want your consumer to provide a way to get/set a specific concrete type.
Today, a consumer can express this idea by a Key Path, a wonderful concept in Swift. My consumer can tell me:
- This is how you can get a String from MyObject (KeyPath)
- This is how you can mutate a String on MyObject (WritableKeyPath)
Commonly, though, you want to ask a consumer a different set of questions:
- Give me a way to retrieve a String on an arbitrary object
- Give me a way to mutate a String on an arbitrary object
While not caring what is the Root of that String, as long as you fulfil the concrete requirement.
Unfortunately, as of today there’s no way to express a Key Path which isn’t bound to a specific concrete Root.
A primary goal of the proposed registry service is to provide strong guarantees that the package you downloaded is authentic. One approach is built on trust: If you assume that a registry always sends you exactly what you ask for, you only need to verify the sender (though it wouldn’t hurt to verify the contents anyway).
Modern information security relies on public-key cryptography to verify claims of identity. Broadly speaking, there are two approaches to certificate trust:
- A centralized, hierarchical public-key infrastructure (PKI) scheme, in which certificate authorities (CAs) issue certificates that prove the ownership of public keys. This is the approach taken by TLS, which is used by HTTPS.
- A decentralized, distributed “web of trust” whereby individuals vouch for the identity of one another by signing each others’ keys directly. This is the approach taken by PGP.
The original proposal relies on both TLS and PGP for security; TLS to verify the identity of the registry’s domain (e.g. github.com) and PGP to verify the registry as the creator of the package archive. My thinking was that this “belt and suspenders” approach would offer more security than relying on one alone. Instead, this turned out to be more of a “weak link in the chain”.
Finally, we have Nyan Cat in Swift. 🏳️🌈