Welcome to issue #14 of the weekly brief! Just like Dave Verwer, I’ve been anticipating the final release of Xcode 7.3 — as well as iOS 9.3, OS X 10.11.4, and watchOS 2.2. Xcode 7.3 will include the final version of Swift 2.2. Perhaps the core team will “loop us in” next Monday. 😉

Starter tasks

Suggested by Ehsan Jahromi:

  • SR-306 — Add stable sort algorithm
  • SR-587 — Move Array(count:repeatedValue:) to RangeReplaceableCollection

Suggested by Daniel Eggert:

Plus, a couple from Brian Gesiak from last issue are still up for grabs:

  • SR-906 — Allow XCTestCase.continueAfterFailure to be set
  • SR-875 — Make swift-corelibs-xctest Functional tests regex matching more like FileCheck

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

Repositories

Another repository appeared this week, apple/cups, the Official CUPS Sources. If you aren’t familiar, CUPS is the standards-based, open source printing system developed by Apple for OS X and other UNIX-like operating systems. This code has been around for over a decade (since 1999), so it’s actually pretty incredible to see it being modernized and moved to GitHub! “By popular request, CUPS is now hosted on Github. All bugs have been migrated to the Github issue tracker and the git repository has been updated to contain the missing release tags and branches since 1.7.0. In the coming weeks we will be moving the CUPS.org web site over to Github hosting as well.” I wonder if we’ll see more of Apple’s open source projects move to GitHub? I sure hope so. 😎

Commits and pull requests

Daniel Eggert from objc.io submitted a pull request to implement NSHTTPURLResponse in corelibs-foundation. 👏

Max Howell ported Swift Package Manager to Swift 3.

Nate Cook patched .flatten for collections for the new indexing model.

John Regner submitted a pull request to move code formatting logic from SourceKit to libIDE as part of SR-146 which aims to create a swift-format tool.

John Holdsworth fixed the majority of Xcode 7.3b5 “Quick Help” crashes in SourceKit. 😎 I’ve never heard of SourceKit crashing. 😉

@practicalswift added a few more test cases for compiler crashes.

Janek Spaderna fixed a crash in AST/sema when referencing an enum case in a where-clause. This now produces the correct error message instead of crashing. It looks like this was originally discovered by @practicalswift.

Proposals

Erica Sadun’s proposal, SE-0039: Modernizing Playground Literals, has been accepted for Swift 3. “The community and core team uniformly agree that this proposal increases uniformity in the swift language.” Chris Lattner filed SR-917 to track this work. “Implementing this would be a great starter task for someone interested in getting involved in the compiler.” 👍

Jesse Rusak’s proposal, SE-0037: Clarify interaction between comments and operators, has been accepted. “There was little community discussion, but the core team and the community participants both agree that this clarifies a corner case in the language.” Work for this is being tracked at SR-960.

Jake Carter and Erica Sadun’s proposal, SE-0046: Establish consistent label behavior across all parameters including first labels, has been accepted for Swift 3. “There was uniformly strongly positive reception to this proposal from both the community and core team. This increases the predictability and consistency of the language, and removes a common source of confusion.” 🎉 This work is being tracked in SR-961.

Ilya Belenkiy’s proposal, SE-0025: Scoped Access Level, was sent back for further revision, but it sounds like the core team is really interested in this idea. While they believe this fits well with Swift’s development methodology, they are concerned about confusion between local and private.

The requested revision involves the proposed keyword, local. The core team feels that the most appropriate keyword for the proposed functionality is the existing private keyword. Other languages that have private access specifiers more closely align with the proposed locally-scoped behavior, so such a change would reduce friction for developers moving between the language and more naturally align when what the core team felt the keyword private implies.

Specifically, the core team is requesting a revised version of the proposal that changes the semantics of the existing private keyword to match those of the proposed local keyword, and introduce a new name for the existing private semantics that more strongly implies file-private access. Because this is a significant expansion in the scope of the change, the core team feels that we should have a second public review.

Michael Ilseman’s proposal, SE-0044: Import as member, is now under review. “This proposal seeks to provide a mechanism for C API authors to specify the capability of importing functions and variables as members on imported Swift types. It also seeks to provide an automatic inference option for APIs that follow a consistent, disciplined naming convention.”

Joe Groff’s proposal, SE-0042: Flattening the function type of unapplied method references, is now under review. “We should change the type of an unapplied method reference to produce a flattened function value, instead of a curried one. This will make unapplied methods more readily useful with real Swift libraries, and make them supportable for mutating methods.” Currently you can do things like pass the global + operator to reduce, for example: arrayOfInts.reduce(0, combine: +). However, you cannot do the same with a binary method like Set.Union, for example: arrayOfSets.reduce([], combine: Set.union). This proposal would allow the latter.

Andrew Bennett’s proposal, SE-0043: Declare variables in case labels with multiple patterns, is now under review. “In Swift 2, it is possible to match multiple patterns in cases. However cases cannot contain multiple patterns if the case declares variables. This change reduces repetitive code, and therefore reduces mistakes. It’s consistent with multi-pattern matching when variables aren’t defined.”

Adrian Kashivskyy and Erica Sadun’s proposal, SE-0047: Defaulting non-Void functions so they warn on unused results, is now under review. “In Swift’s current incarnation, annotating methods and functions with @warn_unused_result informs the compiler that a non-void return type should be consumed. It is an affirmative declaration. In its absence, ignored results do not raise warnings or errors. […] Unused results are more likely to indicate programmer error than confusion between mutating and non-mutating function pairs. This proposal makes ‘warn on unused result’ the default behavior for Swift methods and functions.”

Mailing lists

Max Howell posted that he would like to resurrect the proposal for a protocol for third-party testing frameworks in SPM.

Daniel Eggert started a discussion about implementing NSURLSession by wrapping libcurl. Philippe Hausler replied with some interesting notes on corelibs-foundation and porting these APIs to Linux.

The discussion of David Hart’s draft proposal, Referencing Objective-C key-paths, continued. This would remove yet another case of stringly-typed code for KVC/KVO. “This proposal seeks to improve the safety and resilience to modification of code using key-paths by introducing a compiler-checked expression.” Community feedback is positive.

Yuta Koshizawa proposed making throws syntactic sugar for Result<T>, to “to unify throws and Result into one feature to keep the language simple.” Joe Groff responded thoughtfully with more details about the core team’s decision on Swift’s error handling model and the reasoning behind it.

We extensively discussed adding a Result type internally, but ultimately couldn’t justify it. The only real use case we could see in the wild was for threading errors through CPS-inversion-style abstractions like async promises, something we hope to provide proper language support for. More generally, expressing effects as monadic values is a pretty awful abstraction; aside from polluting the Internet with an endless deluge of unhelpful tutorials, they also don’t compose cleanly, they impose nesting where is desired — you have to pick between Result<Async<T>> and Async<Result<T>>, or build ResultT<AsyncT<Identity>><T> out of monad transformers — and they don’t do the natural thing when used with other higher-order abstractions — if you’re mapping a throws function over a collection, you probably want to propagate that error like rethrows does, not end up with a collection of Result<T>. I’d rather see us adopt an extensible algebraic effects system, something like http://www.eff-lang.org, which provides a framework for throws, async and other control flow effects to be cleanly composed and abstracted over. I see throws as the first seed of that.

But there’s always Antitypical’s Result library if you still aren’t satisfied.

Joe Groff resumed a previous discussion on compiler directives and Erica Sadun drafted a new proposal for this, Expanding Build Configuration Tests for Simulator and Device targets. “This proposal adds #if target(simulator) and #if target(device) to distinguish whether application code is compiled to run in a simulated environment or on a device.”

Finally

And finally — still not sure about protocol-oriented programming? Try side-effect-oriented programming, but be sure to use value types. Once it’s copied, it’s not your problem anymore. 😂