Issue #98 14 Dec 2017
Written by: Jesse Squires
All the way back in Issue #55 we covered discussions on the swift-evolution mailing list about possibly moving to a “modern” form-based solution for discussion and leaving the mailing lists behind. This week, about a year later, the transition to Discourse.org is starting today! This means the mailing lists will be disabled tonight (US Pacific time) with the transition completing by Monday (Dec 18).
I think most are excited about the move. Given the volume of discussions and the lack of adequate search for the mailing lists, I think this will be a great improvement for the Swift community — not to mention more approachable. If you’ve been avoiding swift-evolution because you aren’t a fan of email (who isn’t?!), then this might be your chance to get more involved. You’ll be able to sign up via email or with your GitHub account.
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-6273): [Compiler] Disallow unconstructible infinite value types
- SR-6243: [Foundation]
_fastEnumerationStorageMutationsPtrisn’t doing anything
- SR-6082: [Driver] Produce a better error message if Swift is run on a system without clang++
Episode 39: Source Compatibility Suite Woes. The source compatibility suite has been useful in catching compatibility issues before official Swift releases are cut, but it leaves much to be desired especially around communication with project maintainers outside Apple.
News and community
Ole Begemann wrote a great post, Why Dictionary sometimes encodes itself as an array. Read on to found out!
From Joe Groff:
Moving from Swift 3 to 4, you may get “overriding declarations in extensions is not supported” errors. Before you panic and refactor everything, try adding
﹫objcback to class extensions.
Commits and pull requests
Ben Cohen opened a pull request to eliminate
ArraySlice from the std lib in favor of using
Slice with conditional conformances.
Robert Widmann fixed four SR issues dealing with infinite recursion.
Slava Pestov fixed an issue regarding non-polymorphic constructors.
The standard library should include methods for finding the last element in a sequence, and the index of the last element in a collection, that match a given predicate.
The standard library currently has methods that perform a linear search to find an element or the index of an element that matches a predicate: […]
Unfortunately, there are no such methods that search from the end. Finding the last of a particular kind of element has multiple applications, particularly with text, such as wrapping a long string into lines of a maximum length or trimming whitespace from the beginning and end of a string.
You can work around this limitation by using the methods above on a reversed view of a collection, but the resulting code is frankly appalling.
This proposal introduces a new
DynamicMemberLookupProtocoltype to the standard library. Types that conform to it provide “dot” syntax for arbitrary names which are resolved at runtime - in a completely type safe way. It is simple syntactic sugar which has a non-invasive implementation in the compiler.
Swift is well known for being exceptional at interworking with existing C and Objective-C APIs, but its support for calling APIs written in scripting languages like Python, Perl, and Ruby is quite lacking.
During the discussion on multi-line spring literals a mode for “raw-mode” strings was discussed but postponed for later consideration. This proposal looks to move this idea forward and suggests the smallest of changes be made to the Swift lexer to allow the entry of single and multi-line “raw” string literals by prefixing them with “r”. This adopts the precedent from the Python language. In raw literals, the \ character would have no special meaning.
One area where this form of quoting would be useful is entering regular expressions. As patterns can often contain elements such as \w or \S these do not translate well to the existing string literal syntax resulting in strings such as
let sentence = "\\w+(\\s+\\w+)\\.". This is sometimes referred to as the “picket fencing” problem. Another example is entering windows file paths.
Nicole Jacque announced a proposal and timeline for the transition to Discourse.org! I recommend reading the full email for details. Nicole covers the forum structure (categories, tags, etc.), creating accounts (email or GitHub), and upvoting.
Below is a summary proposal for our move to Discourse. Please note, that unless there are any serious objections, we’d like to do this transition over the next weekend, so please communicate any issues that you may see as soon as possible. Please file issues/comments/requests at bugs.swift.org under the “Project Infrastructure” component for tracking.
In order to get the transition done, and work through any post-transition issues before many of the Swift infrastructure maintainers are on winter holiday break, we’d like to move forward soon — we propose starting the transition on the afternoon (US Pacific time) of Thursday, Dec. 14, and completing the transition by Dec 18 (Monday). This means that email from the mailing lists would be disabled on the evening of the 14th in order to do a final import of mailing list data. One final email would be sent out to the lists when the forums are up and ready for use.
The following @swift.org email lists will continue to function during and after the transition:
And finally — iceage? 🤔