Issue #14 17 Mar 2016
Written by: Jesse Squires
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. 😉
Suggested by Ehsan Jahromi:
- SR-306 — Add stable sort algorithm
- SR-587 — Move
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
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
Max Howell ported Swift Package Manager to Swift 3.
Nate Cook patched
.flatten for collections for the new indexing model.
John Holdsworth fixed the majority of Xcode 7.3b5 “Quick Help” crashes in SourceKit. 😎 I’ve never heard of SourceKit crashing. 😉
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.
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
The requested revision involves the proposed keyword,
local. The core team feels that the most appropriate keyword for the proposed functionality is the existing
privatekeyword. 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
privatekeyword to match those of the proposed
localkeyword, 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.”
Max Howell posted that he would like to resurrect the proposal for a protocol for third-party testing frameworks in SPM.
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
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
throwsfunction over a collection, you probably want to propagate that error like
rethrowsdoes, 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
asyncand other control flow effects to be cleanly composed and abstracted over. I see
throwsas 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.”
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. 😂