It has at this point already been more than two and a half weeks since WWDC. While many are looking into the new tech announced there, as well as playing with the beta software, this is what has been going on in the Swift.org open source projects over the last two weeks.

Interested in sponsoring Swift Weekly Brief? Learn more here.

News and community

Brennan Saeta shared that Swift for Tensorflow will be holding weekly open design meetings.

Johannes Weiss shared the release of grpc-swift, the first Swift gRPC (Remote Procedure Calls) built on top of SwiftNIOHTTP2.

The second Server Side Swift Conference will be held on October 30th and November 1st, 2019, in Copenhagen, Denmark.

Commits and pull requests

Doug Gregor merged a pull request implementing composition of property wrappers.

A pull request was merged that makes Dictionaries to not be rewritten into a call expression after type checking. The new way is to keep the LiteralExpr around and just stash a reference to the right initializer.

Davide Italiano merged a pull request that fixes a bug by simply removing code!

Owen Voorhees opened a pull request fully qualifies names for types with the same name in either different modules, or different scopes. The diagnostic would be really confusing, and this change improves that.

Slava Pestov merged a pull request cleaning up the implementation of lazy property’s underlying storage.

Proposals in review

SE-0258: Property Wrappers is under a second review.

Doug Gregor has provided the following list of differences from the previous revision:

  • The name of the feature has been changed from “property delegates” to “property wrappers” to better communicate how they work and avoid the existing uses of the term “delegate” in the Apple developer community
  • When a property wrapper type has a no-parameter init(), properties that use that wrapper type will be implicitly initialized via init().
  • Support for property wrapper composition has been added, using a “nesting” model.
  • A property with a wrapper can no longer have an explicit get or set declared, to match with the behavior of existing, similar features (lazy, @NSCopying).
  • A property with a wrapper does not need to be final.
  • Reduced the visibility of the synthesized storage property to private.
  • When a wrapper type provides wrapperValue, the (computed) $ variable is internal (at most) and the backing storage variable gets the prefix $$ (and remains private).
  • Removed the restriction banning property wrappers from having names that match the regular expression _*[a-z].*.
  • Codable, Hashable, and Equatable synthesis are now based on the backing storage properties, which is a simpler model that gives more control to the authors of property wrapper types.
  • Improved type inference for property wrapper types and clarified that the type of the wrappedValue property is used as part of this inference. See the “Type inference” section.
  • Renamed the value property to wrappedValue to avoid conflicts.
  • Initial values and explicitly-specified initializer arguments can both be used together; see the @Clamping example.

An amendment for SE-0240: Ordered Collection Diffing is under review.

This amendment is to add a new method, inverse(), to the CollectionDifference type.

Swift Forums

Michael Gottesman shared what Swift support in CMake means for Swift’s build.

I was thinking about this a little bit and I actually think that there are two additional motivating actions here we are not considering:

  1. We could use this to break the dependency of Swift based tools (e.x. swift-syntax) that Swift’s CMake builds on building the standard library.

  2. CMake for free will let us integrate Swift code into swiftc itself trivially.

You can read the full overview here.

Ankit Aggarwal shared that he has been working on test discovery on Linux.

I’ve been slowly working on test discovery for Linux and I think the implementation is in a reasonable state now. I’ve tested it on some OSS Swift packages but it would be great if others can try it out and report any issues they run into. It can be enabled by passing the --enable-test-discovery flag to the swift test invocation.

Ian Partridge shared meeting notes for the June 12th Swift Server Working Group meeting.

Docker: Mishal joined to discuss publishing nightlies to Docker Hub. Happy to scope out doing this - it would involve some infra work from Apple but in principle happy to do this. We would prioritise Swift 5.1 convergence nightlies, add master afterwards. Would prioritise having the latest build available, historical builds can come later. Just full images, not slim.

Ubuntu 14.04 update: there are still users although usage is believed to be low. Mishal will check the stats. When we switch it off, we’ll start with master.

Naming collisions: Johannes explained the current status, post discussions around WWDC. There are a number of separate but related problems.

Artem Redkin created a proposal for an HTTP Client Library.

There are a number of projects implemented their own HTTP client libraries. This shows that there is a need for generic, multi-purpose, non-blocking, asynchronous HTTP client library built on top of SwiftNIO. The Swift Server Working Group aims to provide a number of packages that could be shared between different projects, and I think the proposed HTTP client library would be a good fit for those projects and other use-cases.

Having one, community-driven project that can be shared between different projects will hopefully solve the need to implement this functionality in every project from scratch.

Pavel Yaskevich opened a discussion to document feature/syntax use and error/warning scenarios for proposals.

Since we already have ABI, API resilience and Source Compatibility sections in the proposal template I think it might make sense to expand on that and make sure that proposal is considering not only correct syntax/use, but also accounts for (even if basic) scenarios when new feature/syntax is used incorrectly or in an (temporary) unsupported way.

I think it would make sense for proposals to state explicitly, in a separate section, what is supported and what is not (listing possibilities for future improvements), what is the possible initial set of diagnostic messages and some basic error/warning scenarios as well as what are the ways current feature might interact with other features already implemented in the language.

New attributes/keywords could be a good example - it would be very helpful to list contexts where new attribute/keyword could be used and what error message should be used for the rest. What are the special cases and areas of the future improvement e.g. currently could only be used on functions but later support could be expanded to properties and subscripts. How does new attribute/keyword interact with existing ones e.g. @autoclosure vs. @escaping or @autoclosure vs. inout.

I think having documentation like that in the proposal would make implementation as well as code review much easier, and would be generally helpful for posterity.

Matthew Johnson pitched a proposal to move SwiftUI’s Identifiable protocol and related types to the standard library.

Swift UI introduces an Identifiable protocol as well as the related IdentifierValuePair and IdentifierValuePairs types and the identified(by:) method.

I believe that Identifiable is a “currency” protocol with relevance to an extremely broad range of Swift code and should therefore be moved into the standard library along with the related types and method. These will be useful to any generic code that works with values that represent a snapshot of the state of an entity.

Saleem Abdulrasool shared there will be nightly builds for the Android SDK.

I’ve been working on getting nightlies of the Android SDK - the Swift standard library, libdispatch (and swift SDK overlay), as well as libxml2 and curl. Foundation is something which will take a bit more work, but is easily added. These are not exactly perfect, but should get you fairly up-to-date builds of the Swift standard library and libdispatch for the moment.

All of these builds are being done on Windows, but the generated artifacts are consumable on other targets as well (i.e. you can use this with an up-to-date toolchain on Windows, Linux, or Darwin). They currently target Android API level 21.

Finally

No more 🤖 calls.