In the last two weeks, a lot about Swift has been discussed. Proposals, ideas, improvements, and updates galore.

Starter tasks

• TF-67 [Autodiff] BumpPtrAllocating some classes that have SmallBitVector fields
• TF-86 [Tests] Use expectEqual instead of expectTrue
• TF-93 [Graph Program Extraction] Deabstraction should properly diagnose recursion
• TF-130 [Graph Program Extraction] Add API to serialize a @convention(tensorflow) function as a graph

Podcasts

Jesse and JP talk about the pitch for an official style guide & formatter for Swift.

John Sundell and Ted Kremenek talk about Swift 5, looking at ABI stability and what it means for the future of the language.

News and community

Swift 4.2.3 for Linux was released!

Keith Smiley shared an overview of Xcode build settings to compiler flags for Swift memory exclusivity.

Jordan Rose shared an interesting easter egg: the magic number for swiftmodule files is E2 9C A8 0E, or ✨14, referring to the initial name for Swift and its (planned) release year.

The Server Side Swift Conference posted all its videos from their latest event.

Ray Wenderlich created an overview of Server Side Swift resources.

Swift will once again participate in the Google Summer of Code project this year.

Jordan Rose shed some more light on Swift’s initial “Shiny” name and where this can still be found within the project. ✨

Proposals in review

SE-0243: Integer-convertible character literals is under review.

Swift’s String type is designed for Unicode correctness and abstracts away the underlying binary representation of the string to model it as a Collection of grapheme clusters. This is an appropriate string model for human-readable text, as to a human reader, the atomic unit of a string is (usually) the extended grapheme cluster. When treated this way, many logical string operations “just work” the way users expect.

However, it is also common in programming to need to express values which are intrinsically numeric, but have textual meaning, when taken as an ASCII value. We propose adding a new literal syntax takes single-quotes ('), and is transparently convertible to Swift’s integer types. This syntax, but not the behavior, will extend to all “single element” text literals, up to and including Character, and will become the preferred literal syntax these types.

SE-0244: Opaque Result Types is under review.

This proposal introduces the ability to hide the specific result type of a function from its callers. The result type is described only by its capabilities, for example, to say that a function returns a Collection without specifying which specific collection. Clients can use the resulting values freely, but the underlying concrete type is known only to the implementation of the function and need not be spelled out explicitly.

Swift Forums

Saleem Abdulrasool shared an interesting progress update on Swift on Windows.

After the Swift/Win32 post, I figure that some people may be curious as to the actual state of Swift for Windows. Well, I would like to share a small status update to that end.

This has been a rather interesting and fun journey. I feel that up until this point, we have been making progress, but the surface area is pretty high, particularly for a single person to take on. I have been chipping away at this for a while now. However, as of today, I think that the situation is about to change. I have finally managed to get the compiler, the support libraries, the runtime, standard library, libdispatch, and now, Foundation to build and run on Windows!

Awesome work! 🎉

Joe Groff pitched a proposal that introduces a shorthand for combined protocol and associated type constraints without naming the constrained type.

Swift’s notation for generic constraints generally requires naming the things being constrained; you say that a particular generic parameter conforms to a protocol by naming the generic parameter and the protocol it conforms to, like <C: Collection>, and you put further constraints on its associated types by naming them in a where clause, like C.Element: Equatable. However, opaque result types, generalized existentials, and other conceivable future language features need a way to describe constraints on a type that doesn’t otherwise have a name; an opaque type is intentionally hidden from the interface, and an existential’s contained type is dynamic and can change at runtime. I can see this evolving into its own major design discussion so I figured it’s a good idea to spin this off from the initial opaque result types proposal.

To kick things off, I’d like to suggest borrowing another idea from Rust here: In Rust, you can use T: Trait<Assoc = Type> as shorthand for a combined constraint that T implements Assoc and that T.Assoc is same-type-constrained to Type, as if you’d written T: Trait where T.Assoc = Type. This shorthand can also be used in Rust’s equivalents of opaque types (impl Trait<Assoc = Type>) and existentials (dyn Trait<Assoc = Type>) in addition to generic type constraints. If we were going to do something similar for Swift, we could generalize it a bit so that the shorthand can be used for both protocol and same-type constraints on associated types and to allow constraints between associated types. The result might look something like this:

// Leading dot is used to refer to an associated type
T: Protocol<.Type == Int> // T: Protocol where T.Type == Int
T: Protocol<.TypeA == .TypeB> // T: Protocol where T.TypeA == T.TypeB
T: Protocol<.Type: OtherProtocol> // T: Protocol where T.Type: OtherProtocol

Tony Allevato and Dave Abrahams pitched a proposal to introduce an official style guide and formatter for Swift.

We propose that the Swift project adopt a set of code style guidelines and provide a formatting tool that lets users easily diagnose and update their code according to those guidelines.

At the time of this writing, there is no single style agreed on by developers using Swift. Indeed, even Apple’s own Swift projects on GitHub—such as the standard library, Foundation, Swift NIO, and so forth—have adopted their own varying styles. Furthermore, in many cases the code in those projects—despite the owners’ best efforts—is not always completely consistent in terms of style.

Michael Ilseman pitched a proposal to introduce the concept of contiguous strings.

One of the most common API requests from performance-minded users of string is a way to get direct access to the raw underlying code units. Now that Swift 5 uses UTF-8 for its preferred encoding, we can provide this.

“Contiguous strings” are strings that are capable of providing a pointer and length to validly encoded UTF-8 contents in constant time.

Johannes Weiss has announced that development for Swift 4.2.4 for Linux is now open.

Having released Swift 4.2.3, the February 2019 release where we could land a good number of fixes, we’re now happy to open the development of Swift 4.2.4 for Linux.

Finally

The Swift team has a new emotional support dog! 🐶