Issue #30 14 Jul 2016
Written by: Jesse Squires
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.
- 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.Protocolis considered ObjC-compatible, but crashes
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
Joe Groff added preliminary SILGen and runtime support for importing Objective-C
id as Swift
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!
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!
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:
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!
The community and core team agree that this proposal is a huge step forward that enriches the experience working with and extending the Cocoa
NSErrormodel in Swift. The core team requests one minor renaming of “attemptRecovery(optionIndex:andThen:)” to “attemptRecovery(optionIndex:resultHandler:)”. It also discussed renaming
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!
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.
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!
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.
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!
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
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.
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
partitionmethods, 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.
The standard library additionally defines the following 4 variants, which accept operands of Optional type, with the semantics that
.none < .some(_):
This proposal removes the above 4 functions.
This proposal addresses
alignOf. It discards the value-style standalone functions and combines the remaining items into a unified structure.
sizeof(), etc are treated as terms of art, these names are appropriated from C. The functions do not correspond to anything named
sizeofin LLVM. Swift’s six freestanding memory functions increase the API surface area while providing lightly-used and unsafe functionality.
These APIs are not like
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.
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.
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) -> Intto
(Int) -> Int. However, there is also an implicit conversion from
(Int) -> Intto
(b : Int) -> Int. This means that the compiler currently allows converting from
(a: Int) -> Intto
(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) -> Voidto
(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.
And finally — Check out Swift’s new FiPri district. 😂