I’m starting to get more excited about WWDC by the day right now. Looking forward to meeting people and learning about all new technologies and APIs that we will be seeing. It feels so long ago since last year’s WWDC!

Also, if you’re there too, feel free to say hi! 👋

That being said, here is another two weeks of interesting Open Source Swift news, including another few awesome proposals (I am not complaining, but what happened with that March 1 “deadline”?) and interesting announcements.

Enjoy!

Starter tasks

  • SR-7562 [Compiler] @discardableResult is disregarded for a required init method
  • SR-7574 [Compiler] Use libfuzzer on the demangler
  • SR-7624 [Compiler] Fixits for ‘Argument passed to call that takes no arguments’
  • SR-7629 [Compiler] Wrong fixit when the type doesn’t conform to a public protocol

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

Swift Unwrapped

In episode 57, Jesse and JP discuss the Swift for TensorFlow Design Overview that we mentioned two weeks ago.

In episode 58, Jesse and JP discuss the reimplentation of Implicitly Unwrapped Optionals (IUOs) in Swift, and what that brings us.

News and community

Nicole Jacque and Mishal Shah announced a community hosted Swift continuous integration to make it easier to support more platforms for Swift.

Ted Kremenek announced that Swift for TensorFlow will be developed on a tensorflow branch on apple/swift, allowing closer collaborations among the Swift and TensorFlow teams.

Brian Gesiak wrote an article on how Swift and Clang use LLVM to read files into memory.

Commits and pull requests

Doug Gregor merged a pull request that eliminates more of SubstitutionList. In a followup pull request all remaining SubstitutionLists have been removed.

Introduced during the bring-up of the generics system in July, 2012, Substitution (and SubstitutionList) have been completely superseded by SubstitutionMap.

Pavel Yaskevich merged a pull request that speeds up type checking for large array literals.

Andrew Trick merged a pull request to speed up dynamic exclusivity checks in optimized builds.

Accepted proposals

SE-0207: Add an allSatisfy algorithm to Sequence was accepted with revisions.

The core team accepted one of the two proposed Sequence extensions, with a different name than was proposed:

extension Sequence {
  /// Returns a Boolean value indicating whether every element of the sequence
  /// satisfies the given predicate.
  func allSatisfy(_ predicate: (Element) throws -> Bool) rethrows -> Bool
}

You can find more details about the decision behind the new name in the announcement.

SE-0210: Add an offset(of:) method to MemoryLayout was accepted.

The proposal is accepted as written. Thanks to everyone who participated in the review.

SE-0212: Compiler Version Directive was accepted.

SE-0212 — Compiler Version Directive has been accepted. There was no major concerns about the proposal.

SE-0213: Literal initialization via coercion was under review and consequently accepted.

T(literal) should construct T using the appropriate literal protocol if possible.

Currently types conforming to literal protocols are type-checked using regular initializer rules, which means that for expressions like UInt32(42) the type-checker is going to look up a set of available initializer choices and attempt them one-by-one trying to deduce the best solution.

The core team discussed this today. A line has to be drawn somewhere between this special syntactic rule and a general higher-order use of initializers as functions; let f = T.init is not going to preserve the special rule.

In that light, it makes sense to the core team to tie the special behavior to the existing special syntactic rule of type construction: currently, a “call” of T directly is recognized as always meaning a call to an initializer, whereas this syntax simply adjusts that to sometimes construct a literal.

T.init is then reserved to always mean a higher-order use of the overloaded initializer set.

Swift Forums

Ted Kremenek announced support for related Swift projects to be discussable on the Swift Forums.

The number of projects in the Swift ecosystem keeps expanding and developers are using them more and more to help build their apps. While not officially a part of the language, they exist to provide a leg up on development with optimizations to accomplish specific sets of tasks.

Related Projects includes access to specific sub-categories that are dedicated to projects within the Swift community and are separate from the Swift language itself. This new section of Swift Forums is launching today with support for a number of projects, including:

  • Kitura
  • SourceKitten
  • SwiftLint
  • SwiftNIO
  • SwiftProtobuf
  • Vapor

Michael Ilseman pitched a proposal to increase the usefulness of Character and approachability of programming in Swift.

String is a collection whose element is Character, which represents an extended grapheme cluster (commonly just called “grapheme”). This makes Character one of the first types encountered both by newcomers to Swift as well as by experienced Swift developers playing around in new domains (e.g. scripting). Yet Character exposes little functionality other than the ability to order it with respect to other characters, and a way to access the raw Unicode scalar values that comprise it.

Devin Coughlin announced that exclusive access warnings will be treated as errors in Swift 4.2.

In the recent Swift 4.2 branch, the existing Swift 4.1 warning about ‘overlapping accesses’ is now an error in Swift 4 mode. This means that projects with this warning will fail to build with the Swift 4.2 compiler.

The warning typically arises when a mutating method that modifies a variable is passed a non-escaping closure that reads from the same variable.

Finally

API design is hard.

gif