Issue #20 28 Apr 2016
Written by: Jesse Squires
Were any of you lucky enough to get a ticket to WWDC 2016?! I’m excited to share that I’ll be attending this year. If you got a ticket too, I’ll see you there! However, if you won’t be at WWDC, don’t worry. There are plenty of other great conferences. 😄 Swift Summit has announced its 2016 conference in San Francisco. It will be held this year on November 7 and 8, and yours truly will be speaking. 🤓 Also, the LLVM Developers’ Meeting will be held on November 3 and 4 in San Jose, CA.
- SR-1340: [Compiler] Implement SE-0068, Expanding Swift
Selfto class members and value types. See the Accepted proposals section below for more details.
- SR-1327: [Compiler] Using
dynamicTypeon a force unwrapped
nilvalue type doesn’t throw an exception.
- SR-1304: [SwiftPM] Handle spaces in path when parsing flags from pkgconfig
Commits and pull requests
Jordan Rose added a fix-it for non-optional bindings initialized with
Joe Groff enabled the importing of Objective-C lightweight generic type parameters into Swift as generic classes.
@codestergit opened a pull request to improve
MutableCollectionType.sortInPlace and other sort related functions to take a throwing closure.
Mike Griepentrog merged a pull request with an initial implementation of
David Grove opened a pull request to implement basic usage of the
_ObjectiveCBridgeable protocol on Linux. 🙇
Joe Groff fixed a leak when a bridgeable value type is dynamically cast to a class type, and the cast fails.
Chris Bailey opened a pull request to further integrate corelibs-libdispatch into corelibs-foundation. 😎
Dave Abrahams opened a preliminary pull request for the new
Set algebra APIs, ready to be merged once the Swift evolution review is complete.
Daniel Dunbar merged changes to SwiftPM to improve the portability of generated Xcode projects.
Lukas Schmidt merged a pull request with some minor refinements to
NSDictionary, removing nested
if let statements. It definitely makes this code more readable. 👌 Don’t forget, small wins like this are everywhere, just waiting to be discovered!
This proposal received a significant amount of positive feedback - many people appreciated the clarification to the model, and the fact that it allows for significantly better performance in some cases as well as much simpler model in many ways. The majority of the feedback and discussion was around the specific names used in various methods. The authors of the proposal incorporated that into the latest version of the proposal (v5) which is available at the URL above.
Thank you to Dmitri Gribenko, Dave Abrahams, Maxim Moiseev and many others for contributing to the proposal, discussing the ideas, as well as to everyone else involved in the massive (ongoing) implementation effort to land this change.
This proposal had light discussion in the community review process, but the core team heavily debated it. It includes two pieces:
- Expanding the existing support for Self to work in value types, and in the bodies of classes.
- Replacing the
x.Self, a purely syntactic change that eliminates the
The core team has accepted the first half for this proposal. This allows the use of “Self” as shorthand for referring to the containing type (in the case of structs, enums, and final class) or the dynamic type (in the case of non-final classes). Most of the discussion in the core team centered around whether people familiar with the former behavior would be surprised by the (more general) behavior when using it in a class, but they came to agree that this is actually a simple and general model, and a helpful point of consistency.
In contrast, there are still a number of concerns with re-branding
x.Self. This may (or may not) be the right ultimate direction to go, but it should be split out of this proposal. There is another outstanding proposal that would eliminate the
Type.selfsyntax as being necessary, and the core team would like to resolve that discussion before tackling
Thank you to Erica Sadun for proposing this! I filed SR-1340 to track implementation work for this, this would be a great starter project for someone interested in getting involved in the Swift compiler.
Proposals in review
Swift currently has support for “optional” requirements in Objective-C protocols, to match with the corresponding feature of Objective-C. We don’t want to make optional requirements a feature of Swift protocols, nor can we completely eliminate the notion of the language. Therefore, to prevent confusion about our direction, this proposal requires an explicit
@objcattribute on each optional requirement to indicate that this is an Objective-C compatibility feature.
When certain Foundation types are imported into Swift, they do not fully take advantage of the features that Swift has to offer developers for controlling mutability of their objects.
This proposal describes a straightforward concept for providing this capability. It describes a set of new Foundation value types which wrap their corresponding reference types. This is a technique used by the standard library. This allows us to:
- Improve the developer experience,
- Increase performance for small types like Date
- Preserving the ability for developers to customize the behavior of most types.
Regarding the performance of these changes:
In microbenchmarks designed to test access time for
Date.timeIntervalSinceReferenceDate, the Swift
structconsistently performed about 15% faster. […]
In microbenchmarks designed to test mutation for a new
Date.addTimeIntervalversus creating new
dateByAddingTimeInterval, the mutation approach was consistently about 40 times faster. […]
The review period has been extended for Stephen Canon’s proposal, SE-0067: Enhanced Floating Point Protocols. “Steve opted to revise his original proposal in order to incorporate great feedback from the original review period. As such, we’re extending the review period in order to get adequate consideration of his new changes.”
Doug Gregor’s proposal, SE-0071: Allow (most) keywords in member references, is under review. I recently ran into this issue trying to add a
case default enum. So far, there’s positive feedback for this proposal. 🙌
The Swift API Design Guidelines consider
enumcases as values that use the lowerCamelCase naming conventions. This means that case names that previously did not conflict with keywords (such as
Repeat) now cause conflicts, a problem that is particularly acute when the naming conventions are applied by the Clang importer (per SE-0005). To mitigate this issue, this proposal allows the use of most keywords after a “.”, similarly to how SE-0001 allows keywords are argument labels.
Function types in Swift use parentheses around their parameter list (aligning with the function declaration syntax, as well as the syntax used to call a function). However, in the degenerate case of a single non-variadic, unlabeled argument with no attributes, Swift allows the parentheses to be omitted. While this saves some parentheses, it introduces some minor problems, is not consistent with other parts of the Swift grammar, reduces consistency within function types themselves, and offers no additional expressive capability.
(Int) -> Float could be written as
Int -> Float instead. This proposal would eliminate the latter. This is another great refinement to the language. These proposals that focus on consistency make me really happy. 😊
In Swift 1.2, we attempted to remove all implicit bridging conversions from the language. Unfortunately, problems with how the v1.2 compiler imported various un-annotated Objective-C APIs caused us to scale back on our ambitions. In the interest of further simplifying our type system and our user model, we would like to complete this work and fully remove implicit bridging conversions from the language in Swift 3.
Tony Parker introduced his proposal on Mutability and Foundation Value Types. As mentioned above, this is currently under review.
Dear swift-evolution denizens,
As you know from our announcement of Swift Open Source and our work on naming guidelines, one of our goals for Swift 3 is to “drop NS” for Foundation. We want to to make the cross-platform Foundation API that is available as part of swift-corelibs feel like it is not tied to just Darwin targets. We also want to reinforce the idea that new Foundation API must fit in with the language, standard library, and the rapidly evolving design patterns we see in the community.
You challenged us on one part of this plan: some Foundation API just doesn’t “feel Swifty”, and a large part of the reason why is that it often does not have the same value type behavior as other Swift types. We took this feedback seriously, and I would like to share with you the start of an important journey for some of the most commonly used APIs on all of our platforms: adopting value semantics for key Foundation types.
John Holdsworth revived a previous discussion on adding multi-line string literals to Swift and even prepared a pull request with an initial implementation. There seems to be a decent amount of interest from the community and Chris Lattner provided a lot of feedback on the idea.
Erica Sadun pitched an idea on requiring proactive overrides for default protocol implementations. She proposes requiring the
override in cases where a class implements a protocol method that is already defined on a protocol extension. Doug Gregor opposes the idea.