This week there were updates from the Swift Server APIs work group, new SPM proposals, great community articles about protocols and standard library collections, and an announcement that swift-evolution (and swift-users) will be moving to Discourse. Given the volume on these particular lists, and the need to easily search, reference, and rehash previous discussions, I think this will benefit the community. It looks like the initial setup and migration may require substantial effort, but the Core Team is seeking help from the community. Read on to learn more!

Starter tasks

• SR-3836: The SubSequence of a Range should be a Range
• SR-1421: sourcekitd-test -help should print help, list available request types

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

News and community

Chris Eidhof wrote a great post, Classes That Conform To Protocols, that explains how to use type-erasers as a workaround until generalized existentials arrive in Swift.

Orta Therox wrote a retrospective on using Swift at Artsy. It’s an incredibly interesting post that actually ends up being more about the pros and cons of adopting React Native instead of converting to Swift. Most importantly, he highlights some major, systemic issues with Apple’s developer tools and ecosystem — in particular the lack of openness (Radar) and lack of extensibility (Xcode).

The Swift Server APIs work group held their second security stream meeting, and posted the meeting minutes.

Daniel Duan wrote a step-by-step guide on how to reply retroactively to an old mailing list thread on swift-evolution. Definitely not very user friendly or efficient. This is the kind of cumbersome experience that the Core Team hopes to mitigate by moving to Discourse.

Ole Begemann wrote a great article, Being a Mutable Collection is not Sufficient to be a MutableCollection, where he dives into the standard library collection protocols and answers why Dictionary is (perhaps unintuitively) not a MutableCollection, among other things.

Commits and pull requests

Dave Abrahams (@dabrahams) opened an initial pull request to rethink the existing Unicode implementation. This work is part of the String Manifesto.

Erik Eckstein (@eeckstein) made changes to link a new re-mangler and de-mangler into the swift runtime library.

Jacob Bandes-Storch (@jtbandes) fixed a crash in conditional compilation parsing and fixed an invalid but allowed use of #if / #endif, which was technically a breaking change. (:trollface:) However, Doug Gregor pointed out that the likelihood of this affecting real-world code was small and the code is obviously invalid. So, the old (incorrect) behavior will not be preserved in Swift 3 mode of the compiler.

Slava Pestov (@slavapestov) fixed an issue (SR-3840) where a closure that reads and writes to a computed parameter picks up the static type and not the dynamic type.

Arnold Schwaighofer (@aschwaighofer) open a pull request to switch over to using the Swift calling convention for Swift functions.

There’s a new repo under the swift-server GitHub organization for the development of cross-platform Security APIs. It’s currently empty except for a README, which has all of the details. It discusses the scope of the project, which SSL implementation to use, and trade-offs.

Accepted proposals

Proposal SE-0149: Package Manager Support for Top of Tree development was accepted.

The review of SE-0149 “Package Manager Support for Top of Tree development” ran from January 24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks to everyone who participated!

Proposal SE-0150: Package Manager Support for branches was accepted.

The review of SE-0150 “Package Manager Support for branches” ran from January 24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks to everyone who participated!

Proposals in review

SE-0151: Package Manager Swift Language Compatibility Version by Daniel Dunbar and Rick Ballard is under review.

This proposal adds support for the Swift compiler’s new “language compatibility version” feature to the package manager.

SE-0152: Package Manager Tools Version by Rick Ballard is under review.

This proposal introduces a “Swift tools version” which is declared for each Swift package. The tools version declares the minimum version of the Swift tools required to use the package, determines what version of the PackageDescription API should be used in the Package.swift manifest, and determines which Swift language compatibility version should be used to parse the Package.swift manifest.

Mailing lists

Continuing the meta-discussions from last week about moving away from the mailing lists to Discourse, Ted Kremenek sent an email regarding the decision from the Core Team:

There was a long thread on swift-evolution about whether we should use modern forum software — like Discourse — as an alternative to the mailing lists we have now. After a long discussion, the Core Team has decided to move swift-evolution and swift-users to Discourse.

There are tradeoffs to moving to a forum. The main advantages are:

• Easy for people to participate without subscribing to the entire mailing list, as well as no need to provide email address to participate. A lot of people have voiced concern that they feel resistance to participate because of needing to subscribe to a mailing list.
• Consistent affordances and rendering of content, including Markdown support. This is really useful for having technical discussions.
• Better searching of topics, archiving, etc.
• More tools for moderation.
• Topic cross-referencing, and consistent organization of topics instead of whatever threading support a mail client provides (which is inconsistent).

I also want to consider moving the -dev lists to the same forum setup as well; but that will be a separate conversation on those lists.

A rollout plan has not been figured out. People are busy and there are logistics to figure out. I will be engaging a handful of members from the community to help with the transition. Specifically, there are those who really value using email for participation on swift-evolution and swift-users, and the goal is to get the forum setup to allow those people to continue to feel effective when using email for discussions on these “lists”.

More details will be announced as they get figured out, but I felt it was important to let the community know about this direction.

David Hart shared a second draft proposal on class and subtype existentials.

I rewrote the draft proposal concerning the class and subclass existentials. Please let me know what you think, especially concerning the class and AnyObject conundrum.

There’s an on-going discussion about compile-time generic specialization, originally started by Abe Schneider:

The current behavior of generics in Swift causes it lose type information at compile time due to the desire of maintaining a single version of the function. This runs counter to how c++ works, which creates a new copy of a function per type, but preserves information to be preserved. This can cause unexpected behavior from the user’s perspective…

Continue reading…

Doug Gregor shared some insights into Swift’s design and how it works:

You can’t figure out the correct function to dispatch entirely at compile time because Swift supports retroactive modeling. Let’s make this a super-simple example…

Continue reading…

Finally

And finally — unsigned math is evil. (gist) If only there were a language and compiler that could mitigate these kinds of issues… 😉