Welcome to issue #30! Swift preview 3.0 is underway, and the Core Team is still pushing through tons of Swift evolution proposals — it’s amazing, and slightly overwhelming! 😅 Because of this, I’m not going to dive too deep into the mailing lists, just like last week.

Starter tasks

  • SR-2025: [SwiftPM] “swift build” usage text should specify defaults
  • SR-2022: [Compiler] Improve the fixit for type checking in switch statements
  • SR-1894: [Compiler] Return type of NSCoding.Protocol is considered ObjC-compatible, but crashes

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

Community

Slava Pestov wrote two excellent (unofficial) blog posts this week on the Swift compiler type system. These are the first of what will be a four-part series, so stay tuned. Each post is extremely well-written and incredibly thorough. If you have any interest in the Swift compiler, you should read these. Oh, and be sure to say thanks to Slava! 🙌

Commits and pull requests

Jordan Rose implemented changes for SE-0025: Scope Access Level (private and fileprivate) that allow public members inside internal types.

Doug Gregor implemented proposal SE-0112: Improved NSError Bridging.

Joe Groff added preliminary SILGen and runtime support for importing Objective-C id as Swift Any.

Jordan Rose updated corelibs-foundation for proposal SE-0025: Scope Access Level (private and fileprivate).

Accepted proposals

Matthew Johnson’s proposal, SE-0115: Rename Literal Syntax Protocols, was accepted.

The community and core team agree that this proposal is a better set of names for these protocols. The core team agrees with the community sentiment that “By” is better than “As” in the protocol names, and has accepted the proposal with this revision.

Thank you to Matthew Johnson and many others for driving this discussion forward!

Erica Sadun’s proposal, SE-0114: Updating Buffer “Value” Names to “Header” Names, was accepted.

The community discussion and core team unanimously agree that this is the right thing to do.

Thank you to Erica Sadun for driving this discussion forward!

The second version of Anton Zhilin’s proposal, SE-0077: Improved operator declarations, was accepted with minor revisions.

This round of feedback focused on naming, both of the attributes for precedence groups and the conventions to use for naming the groups themselves:

  • The community expressed a strong preference for ‘higherThan’ and ‘lowerThan’ precedence relationships over the previously-proposed ‘strongerThan’ and ‘weakerThan’, and the core team agrees that these are better terms of art. The proposal is accepted with these terms revised.

  • The standard library team reviewed the proposed names for the standard precedence groups, and suggests the following minor naming revisions:

    • AssignmentPrecedence
    • TernaryPrecedence
    • DefaultPrecedence
    • LogicalDisjunctionPrecedence
    • LogicalConjunctionPrecedence
    • ComparisonPrecedence
    • NilCoalescingPrecedence
    • CastingPrecedence
    • RangeFormationPrecedence
    • AdditionPrecedence
    • MultiplicationPrecedence
    • BitwiseShiftPrecedence

establishing a convention of <Noun>Precedence for precedence group names. The core team accepts the proposal with these revised standard precedence names.

Thanks Anton for shepherding this proposal through the review process!

Doug Gregor’s and Charles Srstka’s proposal, SE-0112: Improved NSError Bridging, was accepted.

The community and core team agree that this proposal is a huge step forward that enriches the experience working with and extending the Cocoa NSError model in Swift. The core team requests one minor renaming of “attemptRecovery(optionIndex:andThen:)” to “attemptRecovery(optionIndex:resultHandler:)”. It also discussed renaming CustomNSError and RecoverableError, but decided to stay with those names.

Thank you to Doug Gregor and Charles Srstka for driving this discussion forward, and for Doug Gregor taking the charge on the implementation effort to make this happen for Swift 3!

Anton Zhilin’s and Chris Lattner’s proposal, SE-0109: Remove the Boolean protocol, was accepted.

The community and core team are overall positive on the removal of the Boolean protocol, under the rationale that it is not pulling its weight and its name is confusing next to Bool. Several members of the core team and a member of the community points out that the functionality provided by the Boolean protocol could make sense for Swift if a well-considered design was available, but the core team feels that we should remove Boolean for Swift 3, and consider adding back a replacement when and if a compelling use-case presents itself to motivate that work.

Tony Parker’s and Philippe Hausler’s proposal, SE-0086: Drop NS Prefix in Swift Foundation, was accepted.

This proposal has evolved greatly from a single bullet item in the original proposal for improving the translation of Objective-C APIs (SE-0005: Better Translation of Objective-C APIs Into Swift). Discussion spawned the transformative work on Foundation value types (SE-0069: Mutability and Foundation Value Types), and other improvements to the mapping of Objective-C APIs into Swift (e.g., SE-0033: Import Objective-C Constants as Swift Types, SE-0044: Import as Member, SE-0112: Improved NSError Bridging) have informed and improved this proposal.

Big thanks to Tony Parker and Philippe Hausler for driving this proposal (and Foundation in Swift) forward!

Proposal SE-0118: Closure Parameter Names and Labels from Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev was accepted.

The proposal has been very well received by the community and core team. The core team agrees with community contributions that ManagedBuffer<Header,Element>.create(minimumCapacity: 10, makingValueWith: makeHeader) should be renamed to makingHeaderWith:. The core team extensively discussed the name of lines.split(whereSeparator: isAllWhitespace) and agreed to keep the name as proposed, because the alternative name lines.split(where: isAllWhitespace) could be confusing given the behavior of dropping the “separator” from the result.

Thank you to Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev for driving this discussion forward! I filed SR-2072 to track implementation of this feature.

Andrew Trick’s proposal, SE-0107: UnsafeRawPointer API, was accepted.

The community and core team agree that this proposal clarifies the rules around the unsafe pointer APIs, while making them “work by default” and balance safety and unsafety in an understandable way. Andy has revised the proposal several times due to community feedback (which is why we extended the review period), which makes my job easier because the core team agrees to accept it nearly as-is :-). The only request from the core team is to remove the default value from the “alignedTo:” parameters of the allocate and deallocate methods, forcing their callers to be explicit about the alignment required by an allocation.

Thank you to Andrew Trick for driving this discussion as well as the implementation forward!

Tony Allevato’s and Doug Gregor’s proposal, SE-0091: Improving operator requirements in protocols, was accepted.

The second iteration of this proposal has been very well received by both the community and core team. The core team requests one minor modification: in an effort to reduce the scope of the proposal, it should specifically require that operator declarations in classes be written as static (or equivalently, as “final class”). In the future, support for operators may be extended to support dynamic dispatch, and the core team wants to keep the design space open. The core team also observed that the impact on the standard library is not captured in this proposal, but that can be incorporated later (as an amendment to this proposal) since it should have little user impact.

Thank you to Tony Allevato and Doug Gregor for driving this discussion forward! I filed SR-2073 to track implementation work on this.

Proposals in review

Adrian Zubarev’s proposal, SE-0119: Remove access modifiers from extensions, is under review.

One great goal for Swift 3 is to sort out any source breaking language changes. This proposal aims to fix access modifier inconsistency on extensions compared to other scope declarations types.

[…] Extensions however behave differently when it comes to their access control:

  • The access modifier of an extension sets the default modifier of its members which do not have their own locally defined modifier.
  • Any type members added in an extension have the same default access level as type members declared in the original type being extended.
  • The access modifier can be overridden by the member with a lower access modifier.

Proposal SE-0120: Revise partition Method Signature from Lorenzo Racca, Jeff Hajewski, and Nate Cook is under review.

This proposal revises the signature for the collection partition algorithm. Partitioning is a foundational API for sorting and for searching through sorted collections.

The standard library’s current partition methods, which partition a mutable collection using a binary predicate based on the value of the first element of a collection, are used by the standard library’s sorting algorithm but don’t offer more general partitioning functionality. A more general partition algorithm using a unary (single-argument) predicate would be more flexible and generally useful.

Jacob Bandes-Storch’s proposal, SE-0121: Remove Optional Comparison Operators, is under review.

Swift’s Comparable protocol requires 4 operators, <, <=, >, and >=, beyond the requirements of Equatable.

The standard library additionally defines the following 4 variants, which accept operands of Optional type, with the semantics that .none < .some(_):

public func < <T : Comparable>(lhs: T?, rhs: T?) -> Bool
public func > <T : Comparable>(lhs: T?, rhs: T?) -> Bool
public func <= <T : Comparable>(lhs: T?, rhs: T?) -> Bool
public func >= <T : Comparable>(lhs: T?, rhs: T?) -> Bool

This proposal removes the above 4 functions.

Erica Sadun’s and Dave Abrahams’ proposal, SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct, is under review for the second time.

This proposal addresses sizeof, sizeofValue, strideof, strideofValue, align, and alignOf. It discards the value-style standalone functions and combines the remaining items into a unified structure.

Although sizeof(), etc are treated as terms of art, these names are appropriated from C. The functions do not correspond to anything named sizeof in LLVM. Swift’s six freestanding memory functions increase the API surface area while providing lightly-used and unsafe functionality.

These APIs are not like map, filter, and Dictionary. They’re specialty items that you should only reach for when performing unsafe operations, mostly inside the guts of higher-level constructs.

Refactoring this proposal to use a single namespace increases discoverability, provides a single entry point for related operations, and enables future expansions without introducing further freestanding functions.

Proposal SE-0123: Disallow coercion to optionals in operator arguments from Mark Lacey, Doug Gregor, and Jacob Bandes-Storch is under review.

Swift provides syntactic sugar for declaring and using them (for example, T? to declare an Optional<T>). As another convenience, Swift provides coercion of non-optional types to optional types…

The convenience of coercing values to optionals is very nice in the context of normal function calls, but in the context of operators, it can lead to some strange and unexpected behavior.

Mailing lists

Chris Lattner provided an update and in-depth commentary on the status of proposal SE-0111: Remove type system significance of function argument labels. It’s a lengthy email, but worth reading.

Shortly after SE-0111 was accepted last week, several people newly noticed the proposal and started a discussion about how it appears to be a regression for closure parameters (e.g. callbacks) that could formerly carry labels, but are now not allowed to. These folks observed that it would be more expressive (and consistent with the rest of Swift) to allow parameter labels in function types, because the invocation site of a closure “should” be required to provide those labels. The core team has been following the discussion, agrees that this is a concern, and wants to update the community with a path forward.

The reality of the situation is that the current implementation of parameter labels in function types is inherently broken. Specifically, as one example, there is an implicit conversion from (a: Int) -> Int to (Int) -> Int. However, there is also an implicit conversion from (Int) -> Int to (b : Int) -> Int. This means that the compiler currently allows converting from (a: Int) -> Int to (b: Int) -> Int, which doesn’t make sense, introduces surprising behavior, introduces complexity into the compiler implementation, and is generally a problem. We do have one specific hack to prevent conversion of (e.g.) (a : Int, b : Int) -> Void to (b : Int, a : Int) -> Void, but this only triggers in specific cases. There are other more complex cases as well, e.g. when using generics T<(a : Int)->Int> cannot be considered compatible with T<(b : Int)->Int>.

These problems are what initially motivated SE-0111. However, given the feedback, the core team went back to the drawing board to determine whether: a) SE-0111 by itself is the right long term answer, b) whether there were alternate models that could solve the same problems in a different way, or c) whether SE-0111 was the right first step to “ultimate glory” in the field of closure parameter labels. After a long discussion, and many alternatives considered, the core team believes in c), that SE-0111 (with a minor modification) is the right step for Swift 3, because it paves the way for the right model over the long term.

…..

Jacob Bandes-Storch shared a mock up of a new proposal status site that he hacked together. 😎 It’s a work-in-progress and it’s not clear if the main swift-evolution repository will adopt this, but it’s pretty cool! If most of the work can be automated, then I think this is a nice improvement over the current README.

Jordan Rose replied to a thread about changing Cocoa APIs, reminding us that the Swift open source project does not control Apple’s APIs. If there are issues with using Cocoa from Swift, be sure to file a radar.

Finally

And finally — Check out Swift’s new FiPri district. 😂