Welcome to issue #102!
- SR-6852 [Compiler] Add support for checking
- SR-6808 [llbuild] Visualizing Build Graph is not exposed from llbuild Build System
- SR-6787 [Stdlib] Unexpected result when getting a String describing a type created inside a function
- 44: Swift Bi-Weekly Brief: Jesse and JP discuss the future of this newsletter.
- 45: Swift News January 2018: They discuss Swift news for January 2018 including starter tasks, Xcode 9.3 beta 1, and commits to Swift source.
News and community
Brian Gesiak published a new article: Getting Started with the Swift Frontend: Lexing & Parsing in his ongoing series Getting Started with Swift Compiler Development.
Point-Free is a video series about functional programming and the Swift programming language. Each episode covers a topic that may seem complex and academic at first, but turns out to be quite simple. At the end of each episode we’ll ask “what’s the point?!”, so that we can bring the concepts back down to earth and show how these ideas can improve the quality of your code today.
Brandon’s talk Server-Side Swift from Scratch also discusses some of the functional programming work they have done with Point-Free.
This article explores what Application Binary Interface means and how it can be important for third-party frameworks.
TL;WR: ABI stability won’t change much for you, and it’s not enough to ship binary Swift frameworks.
Commits and pull requests
Doug Gregor merged a pull request that will allow querying of conditional conformances at runtime. This was the last major part of implementing SE-0143 Conditional conformances which is now complete. 🎉
Runtime query of conditional conformances is now implemented. Therefore, a dynamic cast such as value as? P, where the dynamic type of value conditional conforms to P, will succeed when the conditional requirements are met.
“Removing terminology” is almost always good. Compilers often use terminology that is internal to the implementation, not part of the language model, and can change.
Morten Bek Ditlevsen added Conditional conformances to
Hashable for the following types:
The only revision over the original proposal is to change the syntax to use
#warning <Messsage>. This fits well with most of Swift’s existing compiler directives, and was strongly supported in the review discussion.
The review discussion also covered a variety of possible extensions or variants to this proposal, including support for using
#warningas an expression instead of a line directive and support for runtime issues. The Core Team decided that while these directions are interesting and worth exploring, they are complementary to the core functionality serviced by this proposal. Further, keeping
#warningas a line directive allows it to be used in a wide variety of contexts, and serves a different need than using it as a placeholder expression.
The discussion of SE-0197 made it clear that there is consensus in the community to add the feature. However, several people expressed concern about using the base name remove, since it’s ambiguous about how many matching elements will be removed. There seemed to be broad agreement that
removeAllwould be a better name, with no objections raised during the review. Accordingly, the core team has decided to accept the proposal with the revision that the method be named
We expect this feature to be available in Swift 5.
As always, thank you for helping to make Swift a better language.
Proposals in review
The proposal is accepted in principle, but specific details of the proposal need to be further discussed and ironed out. Specifically, there is the matter of using a marker protocol, which raises a bunch of technical questions.
On the general principle of the proposal, the Core Team felt that:
- This proposal added valuable functionality to Swift
- This proposal is not at odds at potentially adding any new dynamic affordances to Swift later that (say) tie into Swift’s runtime metadata, etc.
- There are tooling affordances, such as syntax coloring, that can be used to distinguish methods call going through this member lookup mechanism — without adding additional syntactic weight that would be at odds of some of the core goals of this proposal.
The standard library currently includes API which allows a type to customize its description in Xcode playgrounds and Swift Playgrounds. This API takes the form of the
PlaygroundQuickLookenum which enumerates types which are supported for quick looks, and the
CustomPlaygroundQuickLookableprotocol which allows a type to return a custom
PlaygroundQuickLookvalue for an instance.
This is brittle, and to avoid dependency inversions, many of the cases are typed as taking
Anyinstead of a more appropriate type. This proposal suggests that we deprecate
CustomPlaygroundQuickLookablein Swift 4.1 so they can be removed entirely in Swift 5, preventing them from being included in the standard library’s stable ABI.
There were a few discussions around Strings this week:
- Brent Royal-Gordon started a discussion on a String interpolation revamp and is looking for some ideas to generate fewer temporary strings. Currenly in Swift interpolation, when you write code like this in Swift 4:
We currently generate code like below which means we create reference-counted heap objects which are purely temporary and are discarded as soon as the string interpolation is finished.
The current sort is problematic because it uses recursion heavily, which defeats a number of optimizations relating to ARC and elimination of the overhead of passing in a closure for the comparative for the comparator. This is why we use
gybto stamp out two near identical versions rather than implementing the
Equatableversion in terms of the closure-taking one.
Today, if your Swift library “Foo” uses a library “Bar”, the headers (or swiftmodule files) of “Bar” must be available to all clients of “Foo”. This is clearly undesirable, especially when “Bar” is just an implementation detail. (It may even be linked statically.)
Let’s look at the changelog for Swift 5. 😃🤣