A busy two weeks: the long-awaiting Swift 5 was released, alongside Xcode 10.2. It took a while, but it is awesome to see this great release come to life.

Furthermore, Swift 5.1 is already being worked on, and there are tons of proposals ongoing, so you can expect a lot more interesting things to come!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

• TF-360 [Tests] Create unit test for TensorFlow.h:convertSwiftTypeToTF
• TF-416 [Python interop] Produce error upon second usage of PythonLibrary.useVersion
• TF-419 Improve tensor printing

Podcasts

In episode 73 of Swift Unwrapped, Jesse and JP discuss UTF-8 Strings in Swift 5.

News and community

Michael Ilseman wrote about UTF-8 String on the Swift.org blog.

Swift 5 switches the preferred encoding of strings from UTF-16 to UTF-8 while preserving efficient Objective-C-interoperability. Because the String type abstracts away these low-level concerns, no source-code changes from developers should be necessary, but it’s worth highlighting some of the benefits this move gives us now and in the future.

SwiftNIO 2 has been released!

Swift 5 has been released! You can find the release notes here.

Commits and pull requests

Nathan Hawes merged a pull request to fix variable renaming in switches.

Slava Pestov merged a pull request that adds support for default arguments on subscripts. 🎉

Ben Langmuir merged a pull request that fixes an infinite looping looking up superclasses, the same day it was reported. 🏎

Accepted proposals

SE-0252: Key Path Member Lookup was accepted.

The review of this proposal has been unanimously positive. Leading up to the end of the review period the feedback tapered off, and the Core Team decided to move ahead and conclude the review a couple days early and accept the proposal.

SE-0249: Key Path Expressions as Functions was accepted.

Hi everyone, The review period has now ended and this proposal has been accepted. Thanks for your feedback during the review!

SE-0248: String Gaps and Missing APIs was accepted.

This proposal has been accepted. Thank you to everyone who participated in the review of this proposal.

SE-0247: Contiguous Strings was accepted with modifications.

The proposal is accepted with one small naming modification: isContiguous and makeContiguous() have been renamed to isContiguousUTF8 and makeContiguousUTF8(), respectively.

SE-0246: Generic Math(s) Functions was accepted with modifications.

Hi, everybody. The review for SE-0246: Generic Math Functions ran from March 11th through the 25th. This review was extended several times in order to make some adjustments in response to feedback gathered during the review. The core team would be interested in getting feedback from reviewers on how they felt about this rapid iteration, and in particular on whether they felt it detracted from the process overall.

Feedback was positive on the general idea of providing a standard way of accessing this functionality. Some suggestions were made that the authors agreed with and chose to immediately incorporate into the proposal, leading to extension of the review period. The main suggestions that weren’t incorporated into mid-review revisions were as follows:

• Several people expressed unhappiness that log meant the natural logarithm (base e). Unfortunately, as observed in the review, the most obvious alternative name for the natural logarithm is ln, which is not a good programming name: it’s too short and too visually similar to keywords like in. log for the natural logarithm is also extensively precedented in many programming languages, including C, Swift’s most obvious antecedent (and the way that people have gained access to this functionality in Swift before this proposal). Ultimately, the core team believes that sticking with log is the best choice even if there’s some risk of people using it when they meant log10 or log2.

• There was a suggestion that create a Math module might create conflicts with names used by other libraries today. The core team agrees that this is an issue which needs further study and work, but decided to define it away for this proposal by simply merging the proposed Math module directly into the Swift module, which already has some similar math functions (such as min and floor); there didn’t seem to be a strong motivation for separating out the functions proposed here.

Therefore, SE-0246 is accepted with the modifications that the Math library should not be added and that the proposed new entities in it should instead be added directly to Swift.

SE-0245: Add an Array Initializer with Access to Uninitialized Storage was accepted.

Based on the review feedback, SE-0245 has been accepted as written. Thank you to everyone who reviewed this proposal and provided feedback!

Returned proposals

SE-0244: Opaque Result Types was returned for revision.

The core team has considered the feedback from the review so far and has decided the proposal should be returned for revision.

This proposal and implementation lay important groundwork, but it is clear from the review that work described in the “future directions” section is necessary to make this a complete and well-integrated language feature. There are also similarities to and differences with another feature of generalized existentials.

In order to better consider this proposal as one of a series of potential additions to the language, the core team is recommending that the proposal authors put together a manifesto outlining in more detail the full arc of these features, similar to the generics manifesto.

The authors expect to be able to present such a document soon, and rework this proposal to fit into that context, at which point we will re-open the review.

Rejected proposals

SE-0243: Integer-convertible character literals was rejected.

The review for SE-0243 has ended and the proposal has been rejected.

To move forward on this topic, and to help the community converge on more of a consensus around these features, the core team recommends breaking this proposal out into two separate proposals that could be re-pitched and (depending on the pitch outcome) re-run.

Proposals in review

SE-0256: Introduce {Mutable}ContiguousCollection protocol is under review.

This proposal introduces two new protocols: ContiguousCollection, which refines Collection, and MutableContiguousCollection, which refines MutableCollection. Both provide guaranteed access to an underlying unsafe buffer.

SE-0255: Implicit returns from single-expression functions is under review.

Swift provides a pleasant shorthand for short closures: if a closure contains just a single expression, that expression is implicitly returned–the return keyword can be omitted. We should provide this shorthand for functions as well.

SE-0254: Static and class subscripts is under review.

We propose allowing static subscript and, in classes, class subscript declarations. These could be used through either TypeName[index] or TypeName.self[index] and would have all of the capabilities you would expect of a subscript. We also propose extending dynamic member lookup to static properties by using static subscripts.

SE-0253: Introduce callables is under review.

This proposal introduces callables to Swift. Callables are values that define function-like behavior and can be applied using function application syntax.

In a nutshell, we propose to introduce a new declaration syntax with the keyword call:

struct Adder {
    var base: Int
    call(_ x: Int) -> Int {
        return base + x
    }
}

Values that have a call member can be applied like functions, forwarding arguments to the call member.

let add3 = Adder(base: 3)
add3(10) // => 13

SE-0252: Key Path Member Lookup is under review.

This proposal attempts to enable stronger-typed version of the dynamic member lookup by extending functionality of an existing @dynamicMemberLookup attribute with key path based variants.

Dynamic member lookup allows a type to opt in to extending member lookup (“dot” syntax) for arbitrary member names, turning them into a string that can then be resolved at runtime. Dynamic member lookup allows interoperability with dynamic languages where the members of a particular instance can only be determined at runtime… but no earlier. Dynamic member lookups, therefore, tend to work with type-erased wrappers around foreign language objects (e.g., PyVal for an arbitrary Python object), which don’t provide much static type information.

SE-0251: SIMD additions is under review.

A few teams within Apple have requested additions to the new SIMD types and protocols to better support their use cases. In addition, there are some features we punted out of the original review because we were up against a hard time deadline to which we would like to give further consideration.

Swift Forums

Joe Groff shares why the closure syntax uses the in keyword.

It’s my fault, sorry. In the early days of Swift, we had a closure syntax that was very similar to traditional Javascript, func (arg: Type, arg: Type) -> Return { ... }. While this is nice and regular syntax, it is of course also very bulky and awkward if you’re trying to support expressive functional APIs, such as map/filter on collections, or if you want libraries to be able to provide closure-based APIs that feel like extensions of the language.

Our earliest adopters at Apple complained about this, and mandated that we support Ruby-style trailing closure syntax. This is tricky to fit into a C-style syntax like Swift’s, and we tried many different iterations, including literally Ruby’s {|args| } syntax, but many of them suffered from ambiguities or simply distaste and revolt from our early adopters. We wanted something that still looked like other parts of the language, but which could be parsed unambiguously and could span the breadth of use cases from a fully explicit function signature to extremely compact.

We had already taken in as a keyword, we couldn’t use -> like Java does because it’s already used to denote the return type, and we were concerned that using => like C# would be too visually confusing. in made xs.map { x in f(x) } look vaguely like for x in xs { f(x) }, and people hated it less than the alternatives.

Nate Chandler pitched a proposal for implicit returns from Single-Expression Functions.

Swift provides a pleasant shorthand for short closures: if a closure contains just a single expression, that expression is implicitly returned — the return keyword can be omitted. We should provide this shorthand for functions as well.

David Smith pitched a proposal to add a String initializer with access to uninitialized storage.

I’ve been working on improving the performance of NSString-to-String bridging, and Michael Ilseman pointed out that the more we can build it out of public API rather than adding a bunch of private stuff for Foundation’s use, the better off everyone is.

This new initializer is designed to be consistent with the recently-accepted similar initializer on Array.

Doug Gregor pitched a proposal to add Property Delegates.

There are property implementation patterns that come up repeatedly. Rather than hardcode a fixed set of patterns into the compiler, we should provide a general “property delegate” mechanism to allow these patterns to be defined as libraries.

This is an alternative approach to some of the problems intended to be addressed by the 2015-2016 property behaviors proposal. Some of the examples are the same, but this proposal is a completely different approach designed to be simpler, easier to understand for users, and less invasive in the compiler implementation. There is a section that discusses the substantive differences from that design at the end of this proposal.

Saleem Abdulrasool shared an update on Swift on Windows.

I think at this point, with pending patches, we should be able to claim that Windows support is as good as macOS and Linux!

I have been working on Foundation as well, which is in a better shape than before. It is possible to build it on Windows, though there is pending work to refactor the build a slight bit which will improve things and enable the nightlies to build Foundation as well. However, getting the library to build is only the beginning and running through the test suite should help get some level of confidence in the library functioning properly.

The Windows instructions have been updated to reflect all of this information, and it should be possible for others to replicate this work as well. Overall, it seems that most of the compiler, runtime, and core libraries are now usable on Windows with the test coverage quickly converging to the point where it is nearly as good as the other supported platforms!

Becca Royal-Gordon pitched a proposal to allow static and class subscripts.

We propose allowing static subscript and, in classes, class subscript declarations. These could be used through either TypeName[index] or TypeName.self[index] and would have all of the capabilities you would expect of a subscript. We also propose extending dynamic member lookup and key paths to static properties by using static subscripts.

Michael Ilseman gave an update on “String Consumption”.

Collection consumers

Processing a string, or any Collection really, typically involves tracking and advancing a position (i.e. an Index). This makes something akin to Slice a great basis to add consuming operations, which advance indices from the front (or back if bidirectional).

There are at least 3 ways to surface this:

1. A new wrapper type
2. Add these to Slice
3. Add these to all Collections that are their own SubSequence

Here’s an example of approach 3, which would put this functionality in a lot of namespaces (Slice, Substring, even Data). Having these broadly available could help discoverability, but we also don’t want to pollute namespaces. These are all “mutating” because they advance indices, but not because they modify the underlying collection. We need to see some usage to evaluate the tradeoffs.

Regex

I wrote more about regexes here Regexes did not make it in Swift 5, but we should still pursue them.

Finally

Syntax is still hard…