Welcome to issue #21! There hasn’t been much news this week other than Xcode 7.3.1 was released, so let’s get on to the weekly brief. It was another huge week for proposals and it feels like the core team is moving really fast ahead of WWDC 2016. 💪

Starter tasks

• SR-1395: [Compiler] Implement SE-0070, Make Optional Requirements Objective-C-only
• SR-1393: [SwiftPM] Enforce Swift module import dependencies

These tasks are from previous issues that are still open and unassigned. Don’t be shy and ask for help if you need it! 😊

• SR-1340: [Compiler] Implement SE-0068, Expanding Swift Self to class members and value types. See the Accepted proposals section below for more details.
• SR-1327: [Compiler] Using dynamicType on a force unwrapped nil value type doesn’t throw an exception.
• SR-1304: [SwiftPM] Handle spaces in path when parsing flags from pkgconfig
• SR-1266: Remove duplication between swift/test and swift/validation-test configuration files. This is a good introduction to the Swift build system, its test suite, and CMake.
• SR-1263: Compiler wrongfully complains of illegal syntax when declaring multiple conformances for a protocol’s associated type.
• SR-1174: [llbuild] Properly escape verbose command descriptions
• SR-580: [Compiler] Warning should be produced for “variable was never mutated”

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

Commits and pull requests

Austin Zheng committed a markdown-formatted version of Doug Gregor’s Completing Generics Manifesto. Really great to have this in the repo instead of buried in the mailing lists!

Guillaume Lessard’s fix for Mike Ash’s weak property thread safety bug was finally merged. 🎉

Bouke Haarsma opened a pull request on SwiftPM to use NSFileHandle instead of fopen, as part of SR-1005. 👍

Max Howell implemented --update in SwiftPM, to determine and apply updates.

Chris Willmore merged a pull request with an initial implementation of SE-0054: Abolish ImplicitlyUnwrappedOptional Type, and made the corresponding changes to corelibs-foundation. 👌

Brian Croom added class-level setUp and tearDown methods on XCTestCase.

Brian Gesiak opened a pull request that implements generating XCTestCaseProvider entries on Linux, SR-710. 😎

@swiftix fixed some Array-related performance regressions introduced by the new indexing model. 🙌

Daniel Duan implemented support for limiting inout capture to @noescape contexts, SE-0035.

Timothy J. Wood implemented his accepted proposal (see below), SE-0061: Add Generic Result and Error Handling to autoreleasepool().

Ankit Aggarwal opened a pull request on swift-llbuild to support -whole-module-optimization. “When enabled swift compiler produces one object file and dependency file for the entire module instead of for each of the sources.”

Accepted proposals

Stephen Canon’s proposal, SE-0067: Enhanced Floating Point Protocols, was accepted for Swift 3. 👏

Overall, the feedback on the proposal was very positive, particularly for revision 2 of the proposal.

The most significant feedback was around the naming issues for the various protocol requirements that map onto operators (e.g. “isLessThanOrEqualTo”). The core team agrees that these are unfortunate - their naming is awkward and they will end up polluting code completion for instances of these numeric types. That said, we are accepting the proposal as written, because the rest of the proposal is great progress in the direction we want to go, accepting it will allow us to get experience living on it, and we can improve this issue with a follow-on proposal.

To address the naming issues, we’d like to explore Tony Allevato’s ideas in the “Improve operator requirements in protocols” thread on swift-evolution. If that doesn’t work out, we request that these members be reworked to be named static members in the protocol, which will address the code completion issue.

Thank you to Stephen Canon for driving the design and implementation of this, and to Max Moiseev (and several others) who have been contributing to the implementation. This is a fundamental step to moving Swift numerics forward!

Doug Gregor’s proposal, SE-0071: Allow (most) keywords in member references, was accepted for Swift 3. 🎉 “The discussion on swift-evolution was minimal, but entirely positive. This proposal eliminates a syntactic problem that would otherwise be new to Swift 3, with no apparent downside. What’s not to love?”

Timothy J. Wood’s proposal, SE-0061: Add Generic Result and Error Handling to autoreleasepool(), was accepted for Swift 3. 🙌 “The feedback on the proposal was minimal, but all positive.” Work is being tracked at SR-842.

Doug Gregor’s proposal, SE-0070: Make Optional Requirements Objective-C-only, was accepted for Swift 3. 🙇 “SE-0070 is the minimal solution for clarifying optional requirements without making their important use cases overtly awkward. The core team requests that the diagnostics generated by mistakes using optional requirements be revised to make it clear that it is an Objective-C only feature.” (A starter task for this listed is above.)

Tony Parker’s proposal, SE-0069: Mutability and Foundation Value Types, was accepted for Swift 3. 😎 “The feedback on the proposal has been overwhelmingly positive.”

Jacob Bandes-Storch’s proposal, SE-0017: Change Unmanaged to use UnsafePointer, was reviewed and accepted for Swift 3. 👍 Jacob proposed replacing the usage of COpaquePointer with UnsafePointer<Void> and UnsafeMutablePointer<Void> in the Unmanaged API to reduce bloated code where users must convert from UnsafePointer to COpaquePointer to Unmanaged.

Kevin Ballard’s proposal, SE-0032: Add find method to Sequence, was reviewed and accepted for Swift 3. 🤓 Kevin proposed to add a new extension method to Sequence called find() that returns the found element. “It’s often useful to find the first element of a sequence that passes some given predicate. […] For Sequences, there’s no easy way to do this besides a manual loop that doesn’t require filtering the entire sequence and producing an array.”

Patrick Pijnappel’s proposal, SE-0052: Change IteratorType post-nil guarantee, was reviewed and accepted for Swift 3. 👌 Patrick proposed to change the behavior of IteratorType.next() to return nil indefinitely.

The feedback on this proposal was generally positive from the community and core team. The most significant concern was about performance: strengthening the requirement on IteratorType.next() could make some implementations of iterators slower. On the other hand, it does make some clients faster (UTF8 decoding being one cited case that demonstrates a big win). The core team believes that the improvements to performance in the most common use-cases will more than balance the reductions in performance for other cases.

Kevin Ballard’s proposal, SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib, was reviewed and a subset of the proposal was accepted with modifications, for Swift 3. 😄 Kevin proposes adding 3 common (but currently missing from the stdlib) Sequence functions — scan(_:combine:), prefix(while:), and drop(while:), with overrides as appropriate on Collection, LazySequenceProtocol, and LazyCollectionProtocol, as well as a global function unfold(_:applying:).

Sequence.prefix(while:) & Sequence.drop(while:) — These are accepted as specified in revision 3 of the proposal.

Sequence.scan(_:combine:) — This addition is rejected by the core team. While this operation is provided by other functional language libraries, its use case is narrow and not obviously as applicable for Swift programmers. Swift intentionally has a high bar for “general utility” when adding operations to the standard library: it isn’t enough to be useful in some cases — it must be broadly useful by lots of people. The core team felt like this was too narrow to be worth including.

unfold(_:applying:) — This addition is rejected by the core team as written, but deserves more discussion in the community, and potentially could be the subject of a future proposal. The core team felt that the utility of this operation is high enough to be worth including in the standard library, but could not find an acceptable name for it. “unfold” is problematic, despite its precedence in other language, because Swift calls the corresponding operation “reduce” and not “fold”. No one could get excited about “unreduce”. “iterate” was also considered, but a noun is more appropriate than an verb in this case. Given the lack of a good name, the core team preferred to reject to let the community discuss it more.

Proposals in review

Joe Groff’s proposal, SE-0060: Enforcing order of defaulted parameters, is under review. “Swift generally follows in the Smalltalk/Objective-C tradition of compound method names with significant, order-sensitive argument labels, but an exception is made for parameters with default arguments. We should remove this exception.”

Félix Cloutier’s and Gwendal Roué’s proposal, SE-0073: Marking closures as executing exactly once, is under review. “This proposal introduces an optional once argument to the @noescape attribute. The @noescape(once) attribute enforces that the closure does not escape, and that it is run exactly once on any code path returning from the function.”

A proposal from Lorenzo Racca, Jeff Hajewski and Nate Cook, SE-0074: Implementation of Binary Search functions, is under review. “Swift does not offer any way to efficiently search sorted collections. This proposal seeks to add a few different functions that implement the binary search algorithm.”

Janosch Hildebrand’s proposal, SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer, is under review. “UnsafeMutablePointer includes several methods to non-destructively copy elements from memory pointed to by another UnsafeMutablePointer instance. I propose adding overloads of these methods to UnsafeMutablePointer that allow an UnsafePointer source.”

Nate Cook’s and Sergey Bolshedvorsky’s proposal, SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++, is under review. “This proposal is to add rotation and in-place reversing methods to Swift’s standard library collections.”

Matthew Johnson’s proposal, SE-0080: Failable Numeric Conversion Initializers, is under review.

Swift numeric types all currently have a family of conversion initializers. In many use cases they leave a lot to be desired. Initializing an integer type with a floating point value will truncate any fractional portion of the number. Initializing with an out-of-range value traps.

This proposal is to add a new family of conversion initializers to all numeric types that either complete successfully without loss of information or throw an error.

Daniel Dunbar’s proposal, SE-0082: Package Manager Editable Packages is under review. “This is a proposal for changing the behavior for iterative development of a group of packages. In particular, we will change the default location to which package dependency sources are cloned, the package managers behavior around those sources, and add a new feature for allowing iterative development.”

Mailing lists

David Sweeris started a discussion on renaming “class” when referring to protocol conformance. Currently, you would constrain a protocol to only apply to reference types by doing protocol P: class { }. Dave Abrahams points out that this has always been an awkward special case that could be replaced with AnyObject. I would love to see this change! To me, protocol P: AnyObject { } is so much more clear and consistent with the language. Adrian Zubarev also brought this up last week.

Nicholas Maccharoli proposed the idea of introducing an OrderedSet type. It looks like Austin Zheng is going to draft a proposal.

Erica Sadun started a thread on adding yes and no to the stdlib as aliases for true and false. However, it looks like community is in favor of keeping a single way to express boolean values.

Sangjin Han started a discussion on MSVC/Cygwin compatibility. I’m personally not very familiar with the technical details here, but it’s an interesting thread!

Finally

And finally — the error message of the day! Bummers. 🤔 😂