Welcome to issue #29! This week Xcode 8 beta 2 was released and a lot of proposals were reviewed, accepted, or rejected. There are well over 100 proposals now. It’s hard to believe we’ve seen so many in such a relatively short time!
Commits and pull requests
Harlan Haskins implemented a fixit for a misplaced
throws, which corrects
func f() -> throws T to
func f() throws -> T. 👌
Ankit Aggarwal opened a pull request that proposes a method of executing tests in parallel in SwiftPM. 🎉
The proposal is accepted for Swift 3 with a minor revision: instead of a
asUnsafeEscapingClosure(_:)function that removes the
@escapingattribute, the core team prefers a function with this signature (roughly) like:
This allows one to safely add the
@escapingattribute in situations where a closure is known not to actually escape. For example, in a situation where you might want to use a lazy algorithm, you could use:
The key to this approach is that the
withoutActuallyEscapingfunction can verify that the closure has not actually escaped when it completes, providing a safe model for locally adding the
@escapingattribute when needed. The core team believes that the actual implementation of
withoutActuallyEscapingwill require some magic, but that it should be implementable.
Many thanks to Trent Nadeau for driving this proposal forward. I filed SR-1952 to track implementation of this feature.
The core team accepted the proposal for Swift 3 with a revision to change the name of the type from “NoReturn” to “Never”.
The feedback on the proposal was generally very positive from the community. The only significant concern was from people who felt that merging the concept of “does not return” into the result type of the function conflates two concepts. The core team feels that unifying these concepts overall reduces the surface area of the language by eliminating an obscure (but important) type system concept outright.
The other significant discussion was about the actual name for the “NoReturn” type. The core team enjoyed the community idea of naming it “💥” or ”🔃” but decided that the name lacked clarity. Ultimately the core team agreed with the loud voice of the community that “Never” is the right name for this type.
Thank you to Joe Groff for driving this proposal forward! I filed SR-1953 to track implementation of this feature.
The feedback from the community was very positive and contributed a number of improvements to the design of the proposal. The core team has accepted the proposal, subject to the following changes:
Integerprotocol should be renamed to
BinaryIntegerto be more accurate and avoid confusion between
FloatingPointprotocol should conform to the
- Rename the
magnitude, and sink it down to the
- Eliminate the
abscan now be defined in terms of
- Rename the
- Add a
popcountproperty requirement to the
- Change the
countLeadingZeros()member of concrete types to be a
func nthWord(n: Int) -> UIntto
func word(at: Int) -> UInt.
- Rename the
doubleWidthMultiplyto be a static member, and add a
doubleWidthDividemember as its dual. The latter will return both quotient and remainder of type
Self. Both are to be added to the
Many thanks to Maxim Moiseev, Dave Abrahams and Dmitri Gribenko for driving this proposal forward, Steve Canon for his important input, and to Maxim Moiseev for driving the implementation work forward.
The community and core team agree that this proposal is the right thing to do, and many agree that this could probably have been treated as a bug fix on a previous proposal.
Thank you to Vladimir S. and Austin Zheng for driving this discussion forward! I filed SR-2008 to track implementation work on this, this would be a great area for someone interested in the type checker to dive into the Swift compiler.
SE-0110 proposal summary:
Swift’s type system should properly distinguish between functions that take one tuple argument, and functions that take multiple arguments. Right now, the following is possible:
The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.
Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.
SE-0111 proposal summary:
Swift’s type system should not allow function argument labels to be expressed as part of a function type.
Right now, argument labels are considered significant by the type system, and the type system establishes subtyping relationships between function types with and without argument labels. Here is an example:
As currently implemented, this feature can lead to surprising behavior. Removing this feature simplifies the type system. It also changes the way argument labels are treated to be consistent with how default arguments are treated; that is, tied to a declaration and not part of the type system.
The community and core team agree that this proposal helps to “round out” the other Swift 3 numerics work. One minor revision is necessary to make the proposal implementable in Swift 3. Since protocol requirements cannot currently have default arguments, the desired behavior should be achieved with two overloads of each operation:
Where the no argument cases can be implemented with a protocol extension that forwards to the single-argument versions. Thank you to Karl Wagner for driving this discussion forward! I filed SR-2010 to track implementation work on this.
SE-0113 proposal summary:
The standard library lacks equivalents to the
ceil()functions found in the standard libraries of most other languages. Currently, we need to import
Glibcin order to access the C standard library versions.
The vast majority of the community of the community prefers to keep this language feature, and the core team agrees. Even though ‘where’ is a small bit of syntactic sugar, it improves the expressivity (therefore readability and maintainability) of important loops.
Many thanks to Erica Sadun for driving this discussion and writing the proposal. This proposal was important and fit with an important goal of Swift 3, which is to re-evaluate all of the existing language features to make sure they are a good for the language over the long term.
The community and core team agree that removing this feature will impose an unacceptable user experience regression for developers using Swift generics, including important protocols like Collection. While we all seek the simplifications to the compiler internals that the proposal would allow, we will have to consider other approaches to achieving that in subsequent releases.
Thank you to Douglas Gregor and Austin Zheng for driving this discussion forward!
The proposal is returned for revision, with the goal for a revised version to make it into Swift 3. The thread discussing it has already turned towards new ways to express these ideas, so when that thread runs its course we’ll restart review of the revised proposal.
While many people were positive about improving lookup of operators, several concerns about introduction of boilerplate were raised. Tony and Doug have discussed it further and plan to revise and resubmit the proposal for another round of review.
Proposals in review
Swift bridges between
ErrorProtocol-conforming types and
NSErrorso, for example, a Swift
enumthat conforms to
ErrorProtocolcan be thrown and will be reflected as an
NSErrorwith a suitable domain and code. Moreover, an
NSErrorproduced with that domain and code can be caught as the Swift
enumtype, providing round-tripping so that Swift can deal in
ErrorProtocolvalues while Objective-C deals in
However, the interoperability is incomplete in a number of ways, which results in Swift programs having to walk a careful line between the
ErrorProtocol-based Swift way and the
NSError-based way. This proposal attempts to bridge those gaps.
This proposal updates parameters and generic type parameters from
All user-facing Swift APIs must go through Swift Evolution. While this is a trivial API change with an existing implementation, this formal proposal provides a paper trail as is normal and usual for this process.
This proposal renames the
The standard library currently has protocols that use the term
Convertiblein two different ways. The
*LiteralConvertibleprotocols use the meaning of converting from a literal. The
Custom(Debug)StringConvertibleprotocols use the meaning of converting to a
String. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.
Objective-C interfaces that use
idand untyped collections should be imported into Swift as taking the
Anytype instead of
idtype is currently imported into Swift as
AnyObject. This is the intuitive thing to do, but creates a growing tension between idiomatic Objective-C and Swift code. One of Swift’s defining features is its value types, such as
Dictionary, which allow for efficient mutation without the hazards of accidental state sharing prevalent with mutable classes. To interoperate with Objective-C, we transparently bridge value types to matching idiomatic Cocoa classes when we know the static types of method parameters and returns. However, this doesn’t help with polymorphic Objective-C interfaces, which to this day are frequently defined in terms of
id. These interfaces come into Swift as
AnyObject, which doesn’t naturally work with value types. To keep the Swift experience using value types with Cocoa feeling idiomatic, we’ve papered over this impedance mismatch via various language mechanisms…
We propose a revision to the names and argument labels of closure parameters in standard library APIs.
The names and argument labels of the standard library’s closure parameters have been chosen haphazardly, resulting in documentation comments that are inconsistent and often read poorly, and in code completion/documentation that is less helpful than it might be. Because of trailing closure syntax, the choice of argument labels for closures has less impact on use-sites than it might otherwise, but there are many contexts in which labels still do appear, and poorly-chosen labels still hurt readability.
Since Swift 1, marking a class
publicprovides two different capabilities: it allows other modules to instantiate and use the class, and it also allows other modules to define subclasses of it. This proposal suggests splitting these into two different concepts. This means that marking a class
publicallows the class to be used by other modules, but does not allow other modules to define subclasses. In order to subclass from another module, the class would be marked
Relatedly, Swift also conflates two similar concepts for class members (methods, properties, subscripts):
publicmeans that the member may be used by other modules, but also that it may be overriden by subclasses. This proposal introduces a new
overridablemodifier, which is used instead of
publicon members that are overridable.
And finally — “Could you write me a nice reference letter?”