Issue #24 26 May 2016
Written by: Jesse Squires
Welcome to issue #24! As noted last week, the first Swift 3 preview branch was cut and now there’s a Swift 3.0 Preview 1 milestone on GitHub tracking pull requests to be included. Currently there are 60 closed and 4 open.
Swift is about to hit another important milestone — 100 proposals. As of this writing there have been 99 Swift evolution proposals merged into the repository, many of them from the community. Swift has only been open source for about 6 months, so that’s over 16 proposals per month — nearly one proposal every other day! I’m pretty sure coordinating, reviewing, and writing swift-evolution announcement emails is Chris Lattner’s new “nights and weekends” passion. 😉
Thus, last week’s announcement about the goals of Swift 3 really should not have been a surprise. I think Dave Verwer said it best, “It’s likely that this volume of high quality community input came as a surprise to the Swift team. Certainly, if it was still closed source, the scope and features of Swift 3 would have been different.”
- SR-1618: [SPM] Xcode re-writes project.pbxproj for more than one module
- SR-1612: Type comparison of certain CG types with AnyObject object is always true
- SR-1453: [SPM] Improve error messages when building invalid packages
- SR-1560: [Compiler] Implement support for SE-0075, Adding a Build Configuration Import Test
- SR-1561: [Parser] implement support for SE-0081, Move
whereclause to end of declaration
Starter tasks are now much easier to discover in JIRA. See the Mailing List section below for details.
Commits and pull requests
Bhaktavatsal Reddy fixed a memory leak in
NSData in corelibs-foundation.
Han Sangjin submitted a pull request to port corelibs-foundation to Cygwin.
Bhargav Gurlanka added support for generating framework targets in Xcode project created by SwiftPM.
Brian Croom opened a pull request to add a command line flag for printing a list of the tests in the suite in corelibs-xctest.
Joe Groff fixed an issue that prevented properly lowering types of Objective-C generic methods dispatched off
Janek Spaderna submitted a pull request to improve diagnostics in inheritance clauses.
Ted Kremenek fixed an issue with
Set that would result in over-allocating the bitmap by a factor of 32 or 64, depending on the platform.
Vivian Kong has opened a pull request on corelibs-foundation to support Linux on IBM z Systems.
Joe Groff fixed crashes when conditionally looking up generic subscripts and properties via
Ankit Aggarwal submitted a pull request that adds a helper tool to list tests from an XCTest bundle on OSX.
The community and core team are both very positive about this massive improvement to the libdispatch APIs. Much of the discussion has centered around specific details in the proposal - for example the “.asynchronously” method on
DispatchQueue. This great discussion leads to several requested revisions in the proposal:
- Rename the
.sync, to follow the term of art.
- Rename Semaphore, Group and WorkItem:
- Expand source handler methods to take the same arguments as
DispatchQueue.afterto take the same arguments as
async()in addition to the
Thank you to Matt Wright proposing this, and for all of the implementation work that has gone into this so far!
- Feedback from the community & core team is positive.
- Core team discussed whether it made sense to add just the first form, or whether it made sense to add both. They agree that although the form using an explicit state is much more infrequently used, when it is necessary, it is extremely helpful to have. It is also useful to consider both as a pair.
- On naming, the core team agrees with the community that
sequence(first:next:)is a better name than
sequence(state:next:)is approved as-is.
Alex Hoppen, who undertook the work to implement the related proposal SE-0064, “Referencing the Objective-C selector of property getters and setters”, noted that by accepting arbitrary expressions inside a
#selectorexpression, we made it difficult to handle the getter and setter selector cases introduced by SE-0064. It was not the original proposal’s attempt to accept arbitrary expressions, only expressions that happened to form a valid method reference, and the amendment seeks to clarify this intent.
The general “rotate a collection by N elements” operation is a powerful operation that is nice to have in certain domains, but also has very narrow applicability. Further, the proposal has high implementation complexity (particularly when dealing with lazy collections) due to missing generics features like constrained extensions. As such, the core team has decided to defer this feature until the dependent generics features are available.
One specific exception to this deferral is the
reverse()algorithm proposed for
BidirectionalCollection. This algorithm is simple and straight-forward, so it is approved for Swift 3.
The core team and much of the community would like to get the predictability wins of this proposal. However, recent experience with the fallout of “SE-0072: Fully eliminate implicit bridging conversions from Swift” has raised some concerns that it may have overly harmed Objective-C APIs designed around the “id” type. Joe Groff will be investigating a few ideas that may help make SE-0072 work better in practice, and until they are explored and understood, the core team prefers to defer discussion on SE-0083.
Once we have clarity on the fate of SE-0072 (in the next 3-6 weeks), we can discuss SE-0083 again. Thank you to Joe Groff for this proposal, and also for helping to sort out the issues related to SE-0072.
The community and core team all want this proposal (or something like it) to succeed, but the core team identified several serious implementation concerns with the proposal:
- Disambiguating type vs expression cannot be done in cases where there is no contextual type available or when that type is
Any. For example, in the case of
let x = [Int]it isn’t clear whether this is an array value that contains the metatype for
Int, or whether it is a metatype value for the type
[Int]. Similar problems exist with tuple literals, including the degenerate case of
let x = ()which can either be the type of the empty tuple type or an empty tuple value.
- As written, the proposal has a defaulting rule that fall back to the container literal when a type literal cannot be formed. The core team prefers that the compiler treat truly ambiguous cases (where a subexpression could be considered to be either a type or a value) to be ambiguous.
- Resolving ambiguous cases requires some syntax to disambiguate between the cases, which we don’t have. This syntax should be part of the proposal.
- Having the constraint solver determine whether a subexpression is in a type or expression context is conceptually beautiful, but it introduces significant complexity into the type checker and puts more pressure onto the constraint solver. The core team would prefer to see the already planned optimizations and simplifications go into the constraint solver before this happens. This would allow us to more accurately gauge the cost of this design in practice.
- The goal of removing the
Int.selfsyntax is a great one, but can be done at any point (beyond Swift 3) at little cost: the goal is to obsolete the
T.selfsyntax, not to repurpose it to mean something else. This means that we can continue to accept it as deprecated syntax for a very long time with little cost to the community.
The core team would definitely like to circle back to this proposal after Swift 3 is out the door, but would recommend that such a proposal be accompanied with a prototype implementation, to validation that the chosen approach can work in practice.
The proposal has been returned for revision and another round of discussion - the core team would love to see the revised proposal make it into Swift 3.
The community and core team both want to remove this “footgun” from the standard library, where someone could write “String(x)” with the intention of getting a value-preserving conversion to String, but may instead get a potentially lossy and potentially expensive reflection-based conversion to a String. After extensive discussion, the core team recommends that the community consider a somewhat more elaborate design…
The feedback from the community was quite divided on this topic…
Swift currently accepts a trailing comma in array and dictionary collection literals, for three reasons: evolution of a project often adds and removes elements to the collection over time, these changes do not alter the type of the collection (so those changes are typically spot changes), and the closing sigil of the collection (a right square bracket) is often placed on the line following the elements of the collection. Because of these properties, accepting a trailing comma in a collection literal can help reduce spurious diffs when elements are added or removed.
That said, these properties do not translate to other comma separated lists in Swift…
The community feedback on this proposal was that the most important thing was for the syntax to align with that of the forthcoming property behavior syntax. The core team does not know what that syntax will be, so it prefers to reject this proposal. […] …it would be worse to switch “lazy” to “@lazy” in Swift 3, only to switch it to something else in a subsequent release.
Proposals in review
Adrian Zubarev’s and Austin Zheng’s proposal, SE-0095: Replace
protocol<P1,P2> syntax with
Any<P1,P2>, is under review. Aside from the positive implications for generics, I think this is a great change to bring further consistency to the language. Repurposing the
protocol keyword for composition always felt awkward and out of place to me. The community feedback on this proposal is positive so far, and Joe Groff has started some bikeshedding on an alternative form of infix syntax for composing constraints.
A stated goal for Swift 3.0 is making breaking changes to prepare the way for features to be introduced in future features, especially those involving the enhancements to the generics system detailed in Completing Generics.
One such change described in Completing Generics is renaming
Any<>in order to allow it to serve as a syntactic foundation for more generalized existential types. This is a straightforward change which will allow a later version of Swift to introduce better handling for existential types without making breaking changes, or changes whose functionality overlaps with that of existing features.
Erica Sadun has three proposals under review this week.
SE-0097: Normalizing naming for “negative” attributes is under review. “This proposal normalizes naming for “negative” attributes by adopting a rule that replaces property names starting with
nowith adjectives starting with
non.” So far there’s limited and mixed feedback from the community. I’m rather neutral on this.
willSetfor more consistent keyword casing is under review. There’s mixed feedback from the community on this one, mostly leaning against the change. It seems like Joe Groff’s concern over potential language churn has shifted opinions: “
willSetare already contextual rather than formal keywords, and there’s a conceivable future where
willSetare no longer keywords at all if we run with the ‘property behaviors’ feature again in the future. If we think that’s likely, I’m not sure this intermediate churn is really worth it.”
dynamicTypeis a property. Because of that, it shows up as an “appropriate” code completion for all values regardless of whether it makes sense to do so or not. For example, Swift offers
myFunction().dynamicType, etc. Unlike most properties, it does not express a logical attribute of a specific type. Instead, it can be applied to any expression. Since
dynamicTypebehaves more like a operator (like
sizeof), its user-facing calling syntax should follow suit.
If you’re like me, you might be curious how Core Libraries like swift-corelibs-xctest are doing with regards to the looming Swift 3.0 release. Well, wonder no more… […] The dashboard not only lists tasks that need to be resolved by Swift 3.0, but also open starter tasks for new contributors.
Following Brian’s lead, Daniel Dunbar announced a dashboard for SwiftPM. Brian also created a dashboard for corelibs-foundation and Philippe Hausler added a bunch of starter tasks. Each of these dashboards make it super easy to manage tasks and discover starter tasks. 👏