Welcome to issue #102!

Starter tasks

  • SR-6852 [Compiler] Add support for checking #if swift(<4.1)
  • 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

Submit a task by sending a pull request or opening an issue.

Swift Unwrapped

News and community

Greg Heo wrote an amazing post about Conditional conformance. In it, he thinks through conditional conformance in Swift, and works through the basics of its implementation.

Brian Gesiak published a new article: Getting Started with the Swift Frontend: Lexing & Parsing in his ongoing series Getting Started with Swift Compiler Development.

Xi Ge’s talk about Creating Refactoring Transformations for Swift from the Swift Summit 2017 is posted. He also talks about future of refactoring engine with libSyntax.

Brandon Williams and Stephen Celis launched a new Swift video series called Point-Free. Checkout their first episode, Functions.

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.

Peter Steinberger wrote about Binary Frameworks in Swift

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.

He also fixed an issue in type checker where class constraints (spelled T: AnyObject) on generic types were not getting checked on generic arguments.

Ben Cohen merged a pull request that has some more excellent uses of conditional conformances in the Swift standard library. Say goodbye to (Closed)CountableRange. 👋

Greg Titus merged a pull request that removes compiler terminology l-value. As mentioned by Slava Pestov:

“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.

Nathan Hawes created a pull request to fix a crash in onDocumentUpdateNotification. This was one of the top SourceKit crashes.

Morten Bek Ditlevsen added Conditional conformances to Hashable for the following types:

Eric Eckstein fixed two issues which prevented incremental LLVM compilation.

Accepted proposals

SE-0196: Compiler Diagnostic Directives was accepted with a minor revision.

The only revision over the original proposal is to change the syntax to use #warning(<Message>) instead of #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 #warning as 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 #warning as 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 proposal was also implemented and merged by Harlan Haskins.

SE-0197: Adding in-place remove(where:) to the Standard Library was reviewed and accepted.

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 removeAll would 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 removeAll(where:).

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

SE-0195: Introduce User-defined “Dynamic Member Lookup” Types is still under review. It’s review was extended by another week.

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.

[…]

SE-0198: Playground QuickLook API Revamp is under review.

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 PlaygroundQuickLook enum which enumerates types which are supported for quick looks, and the CustomPlaygroundQuickLookable protocol which allows a type to return a custom PlaygroundQuickLook value for an instance.

This is brittle, and to avoid dependency inversions, many of the cases are typed as taking Any instead of a more appropriate type. This proposal suggests that we deprecate PlaygroundQuickLook and CustomPlaygroundQuickLookable in Swift 4.1 so they can be removed entirely in Swift 5, preventing them from being included in the standard library’s stable ABI.

[…]

Swift Forums

There were a few discussions around Strings this week:

let foo: MyString = "foo \(bar) baz"

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.

let foo = MyString(stringInterpolation:
	MyString(stringInterpolationSegment: "foo " as String),
	MyString(stringInterpolationSegment: bar),
	MyString(stringInterpolationSegment: " baz" as String)
)

Ben Cohen started a discussion for Revisiting the choice of sort algorithm in the std lib:

Swift.sort is currently an introsort. Introsort is unstable, and there’s been discussion over on evolution of adding a stable sort, either instead of or as well as the current sort.

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 gyb to stamp out two near identical versions rather than implementing the Equatable version in terms of the closure-taking one.

[…]

Jordan Rose started a discussion for @_exported and fixing import visibility:

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.)

[…]

Finally

Let’s look at the changelog for Swift 5. 😃🤣