Welcome to issue #12 of the weekly brief! More huge news this week as the Core Team is now expanding commit access to non-Apple contributors! Congratulations to the following contributors for getting commit access! 🎉 😎 👏

If I missed anyone, please submit a pull request to update the list! 😄 This week also brought us Xcode 7.3 beta 5. We should be getting close to the final release.

Commits and pull requests

The other big news from the past week was Brian Gesiak’s port to Android pull request. This is really awesome to see. 🙇 Note: +1’s are very much appreciated, but can be burdensome for contributors. If you’d like to comment, please send a tweet to Brian instead. 😄

A new repository, swift-compiler-rt, appeared this week. “This directory and its subdirectories contain source code for the compiler support routines.”

Harlan Haskins has opened a pull request that adds a code coverage comparison visualization tool. 🤓

C.W. Betts submitted a pull request to implement NSUserDefaults in corelibs-foundation.

Patrick Pijnappel rewrote UTF8._isValidUTF8() to improve performance and reduce code size. Depending on the sequence, there’s a 15-45% speed-up. This is brilliant! 😎

Nadav Rotem disabled the in-lining of measureExtendedGraphemeCluster. “This change reduced the size of the Swift standard library by about 45k (2% of the .text size).”

Guillaume Lessard submitted a pull request to fix SR-192, “Weak properties are not thread safe when reading”, reported by Mike Ash.

Honza Dvorsky opened a pull request (previous discussion here) to generate XCTestCaseProvider entries on Linux (SR-710).

Ankit Aggarwal submitted a pull request to add support for empty source packages (SR-793).

Daniel Duan opened a pull request to implement proposal SE-0034, which replaces the line directive #line with #setline.

@tinysun212 has started work on a port to Windows (SR-34) and integration with Visual Studio.

Proposals

Erica Sadun’s proposal, SE-0034: Disambiguating Line Control Statements from Debugging Identifiers, has been accepted. “The community and core team both widely agree that this is a straight-forward fix to an uncommonly used feature.”

Daniel Dunbar’s proposal, SE-0038: Package Manager C Language Target Support, has been accepted! I’m really excited about this. I think having C language support in SPM will have a huge impact on the community. “We didn’t get a lot of commentary on this proposal, but there appears to be general support for this proposal. […] While we now have a specification for how this feature should work, we do not yet have a schedule for when we will be able to implement it. If you are interested in contributing an implementation for this proposal, please coordinate with us on the swift-build-dev mailing list.”

David Scrève’s proposal, SE-0026: Abstract classes and methods, is now under review. I’m personally not a fan of this idea. I think that the problems that abstract classes and methods attempt to solve can be better solved with protocols, and design patterns that avoid the need for inheritance in the first place. David Owens II and Austin Zheng offer their views against and in favor, respectively. Overall feedback on the mailing lists is mixed.

Ilya Belenkiy’s proposal, SE-0025: Scoped Access Level, is now under review. It aims to introduce a new access level modifier, local, which would make the specified members private to their class/struct. Support for this is mixed and I can understand both sides. Stephen Celis and Becca Royal-Gordon have written great responses against this. Nate Cook provided his thoughts on why he thinks this is a good change. And Joe Groff suggested that this might be solvable with stored properties in extensions instead.

Erica Sadun drafted two proposals for refinements to Strides. So far there is mixed but mostly positive support for each of these.

  • Conventionalizing stride semantics (here). “Swift offers two stride functions, stride(to:, by:) and stride(through:, by:). This proposal introduces a third style and renames the existing to and through styles.”
  • Decoupling Floating Point Strides from Generic Implementations (here). “Strideable is genericized across both integer and floating point types. A single implementation causes floating point strides to accumulate errors through repeatedly adding by intervals. Floating point types deserve their own floating point-aware implementation that minimizes errors.”

Mailing lists

Dmitri Gribenko posted a request for comment on proposed changes to collection indices.

We would like to propose a major change to how collection indices work. The standard library team has discussed this idea internally and we wrote a prototype. Now we think it is a viable direction to consider, and we are bringing it for wider public discussion.

We are proposing a new model for collections, where indices can only be advanced forward or backward by the corresponding collection instance. Indices become opaque tokens representing collection positions, that can be produced and consumed by collection APIs. This allows us to reduce the amount of data stored in indices to the bare minimum.

Compared to the current state, the new scheme simplifies implementation of non-trivial indices, and fixes concurrency issues in Set and Dictionary indices. It also allows us to eliminate reference-counted stored properties from most indices, including non-trivial ones, like Set.Index and Dictionary.Index, creating more optimizable code.

Chris Lattner made a brief pitch on simplifying class initialization complexity, asking if anyone from the community could drive this project as the core team does not have time.

If anyone is interested in picking up this as a project to scope, design, and drive, that would be great. :-)

Class initialization in Swift support a wide array of knobs and concepts, including things like designated initializers, required initializers, convenience initializers, etc. These are all required by various common patterns in Cocoa and other OO systems, but has an unfortunate side effect: all of the complexity is foisted on you at once.

Wouldn’t it be great if you could freely define a new class and not have to know about required and convenience initializers? It seems that we should only have to enforce these requirements if you a) further derive from this class within your module, or b) mark the class publicly-derivable-from.

Erica Sadun has started a discussion on disambiguating Swift Package Manager naming conflicts (draft proposal here). She suggests using reverse domain names to fully quality packages, for example import org.sadun.SwiftString. Max Howell’s initial response was positive. 😎

Finally

And finally — if you didn’t know, the try! Swift conference is happening this week in Tokyo. Huge thanks to @NatashaTheRobot and the organizers for putting together such a great event. 🙌 Lots of familiar faces from the community are here, and it has been awesome. You can follow the fun on Twitter at #tryswiftconf. I even got to meet Ash Furrow. 😂