Issue #56 09 Feb 2017
Written by: Jesse Squires
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!
Attend a full day of cutting-edge iOS talks ranging from mirroring and introspection to watchOS. Your ticket includes free networking events with speakers/other devs, and 1 free month of online workshop access post event. Add an exclusive in-person workshops by Paul Hudson on beginning or advanced Swift, macOS, and server-side Swift while they last. Use code forward-swift-2017.
- SR-3836: The
Rangeshould be a
sourcekitd-test -helpshould print help, list available request types
News and community
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
Jacob Bandes-Storch (@jtbandes) fixed a crash in conditional compilation parsing and fixed an invalid but allowed use of
#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.
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.
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!
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
This proposal adds support for the Swift compiler’s new “language compatibility version” feature to the package manager.
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
PackageDescriptionAPI should be used in the
Package.swiftmanifest, and determines which Swift language compatibility version should be used to parse the
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.
I rewrote the draft proposal concerning the class and subclass existentials. Please let me know what you think, especially concerning the
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…
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…