Welcome! This week we saw how compile-time cost is being addressed in Swift 3.1. The swift-evolution community discussed ABI stability, and there was also a meta-discussion on possibly moving away from mailing lists to a forum-based solution.
有兴趣赞助 Swift Weekly Brief？点击这里
Starter tasks
- SR-3782: UnsafeMutable[Raw]BufferPointer should have non-mutating subscript setters
- SR-3665: Global functions called with an explicit namespace do not respect
@discardableResult - SR-3773: Class definition not included when running
-emit-sil
Submit a task by sending a pull request or opening an issue.
News and community
Graydon Hoare (@graydon) (Rust creator) wrote a post on Faster Mix-and-Match Builds with Precompiled Bridging Headers for the official Swift blog. The article discusses the compile-time cost of projects that mix Objective-C and Swift and how it is being addressed in Swift 3.1. One interesting thing to note is that the team is explicitly soliciting feedback on Twitter via #SwiftBridgingPCH.
Paul Hudson wrote about What’s new in Swift 3.1. It’s a great overview with examples.
From Joe Groff:
If your Swift code compiles in Xcode 8.2 but not in the 8.3 betas, that’s our fault, not yours. Please let us know by filing bugs!
Commits and pull requests
Colin Howell (@colinhowell) fixed a source of exponential behavior with dictionary literals.
Michael Gottesman (@gottesmm) add a new tool called SILLLVMGen that performs IRGen on a sil or sib file without adding any additional complexity.
Doug Gregor (@DougGregor) merged improvements to the type checker regarding how constraints are generated for interpolated string literals.
Jordan Rose (@jrose-apple) fixed a crash when calling a generic initializer with default arguments.
Slava Pestov (@slavapestov) fixed a batch of compiler crashers. “A fixed crasher a day keeps @practicalswift at bay… or something.”
Graydon Hoare (@graydon) opened a pull request to fix an issue in the constraint solver where it was inaccurately measuring its memory usage threshold.
Dave Abrahams (@dabrahams) fixed a data race in StringBuffer.append.
@saiHemak implemented homeDirectoryForCurrentUser and homeDirectory(forUser:) on FileManager in corelibs-foundation.
Accepted proposals
SE-0148: Generic Subscripts was accepted for Swift 4.
The review of SE-0148 “Generic Subscripts” ran from January 19…24, 2017. Feedback was 100% positive, and the proposal is accepted for Swift 4, along with the amendment to support default arguments for subscript parameters. Thanks to everyone who participated!
Mailing lists
Ben Cohen (@AirspeedSwift) wrote about where the standard library should draw the line in providing convenience functions that can easily be composed from other functions in the standard library.
SE-100 is a proposal to add an
inittoDictionaryfrom a sequence of key/value pairs. It’s a commonly requested feature, and IMO much needed and should be added as soon as we move to the appropriate phase in Swift’s evolution.Another commonly requested
Dictionaryfeature is similar: add aDictionary.initthat takes a sequence, and a closure that maps that sequence to keys. This is useful, for example, when you have a sequence of objects that you frequently need to index into via one property on those objects, so you want to build a fast lookup cache using that property.Now, if we implement SE-100, that second request can be easily composed. It would be something like
Dictionary(sequence.lazy.map { (key: $0.someProperty, value: $0) } )Some people look at that line of code and think sure, that’s what I’d do and it’s easy enough that the second helper shouldn’t be added as it’s superfluous. Others look at it and say that it is unreadable clever-code FP nonsense, and we should just add the helper method because most programmers wouldn’t be able to read or write that easily.
As we expand (and maybe contract :) the standard library, this kind of question comes up a lot, so it is worth setting out some criteria for judging these “helper” methods. Here’s my take on such a list (warning: objectivity and subjectivity blended together in the below).
David Hart started a thread on postponing ABI stability:
ABI stability is an important feature which many Swift users are looking forward to. If I understand it correctly, once it’s here, the Standard Library becomes part of that ABI and only additive and backwards-compatible changes can be done. Seeing how we are still heavily modifying the Standard Library this year (Strings), wouldn’t it be wiser to let those changes simmer under the scrutiny of the broader community of Swift users for a year before we make it into the ABI?
I have had exactly the same worry for quite some time. We’re still waiting for many basic components of the generics system, and, if our experience with protocol extensions is any guide, before we have those features in hand, it will be impossible to anticipate the design changes we’d want to make to the standard library… and that cuts against the grain of source (to say nothing of ABI) stability.
So far I’ve been unable to form a mental model for what source and/or ABI stability actually means for our ability to make changes to the standard library in the future. It’s possible that we discover a workable path forward, but it’s equally possible that we find ourselves painted into a corner.
I fully agree that locking down the ABI prematurely would be detrimental to the long-term future of the language.
Part of the point of the ABI manifesto is to scope out what are the desirable or critical changes needed before ABI gets locked down. From that we can have concrete discussions on what’s left to be done, how much work it will take to get there, etc.
[…] In short, in the Swift 4 / iOS “N” timeframe, the only benefit of ABI stability would be that apps don’t need to include the standard library if they deploy to iOS “N or later”. Independent of whether ABI stability is achievable, I think it is important to do things like merge the dylibs together, since backward deployment will continue to be important for many apps.
Joshua Alvarado has re-opened the discussion on moving swift-evolution away from email toward a forum-based solution.
It is hard to know what has already been discussed and who is even in the active conversation. Keeping track of history is a pain as well. Searching through many emails to find who said what and when is not effective in email clients. Also, code formatting in emails is not effective. Let’s discuss and actually make an action to move away from email if the community so agrees.
Ole Begemann highlighted some common pain points with the current solution: a lack of permalinks to view messages on the web archive, the poor usability of the web archive, and readability due to people using different formatting. Austin Zheng pointed out potential issues with logistics, maintenance, and administrative costs. Finally, Nate Cook took the time to setup a trial account with Discourse to see how importing the existing archives would work!
Project Lead, Ted Kremenek, was open to the idea:
I have no problem with the project moving to forums instead of the Mailman mailing lists we have now — if it is the right set of tradeoffs.
My preference is to approach the topic objectively, working from goals and seeing how the mailing lists are aligning with those goals and how an alternative, such as Discourse, might do a better job.
The current use of mailing lists has been carry-over of how both LLVM does public discussion (which is all mailing lists) and how the Swift team at Apple has used mailing lists for discussion. That inertia has benefits in that it is a familiar workflow that is “proven” to work — but that doesn’t mean it is the best option going forward.
The community was mostly positive about moving away from email for swift-evolution and swift-users (other mailing lists would remain) and agreed that if moving to a forum that Discourse would likely be the best option.
Jordan Rose asked for help on gathering data for a proposal to fix how NSUInteger is treated in Swift.
Hey, swift-evolution. I want to draw attention to one of the oddest parts of the Objective-C importer today:
NSUInteger. TLDR:NSUIntegeris treated differently based on whether it comes from a system framework or a user-provided header file. I think this is silly and that we should treat it consistently everywhere, but I haven’t had time to go collect data to demonstrate that this is a safe change. Would someone like to take that on? […]
Finally
And finally — Forget about unwrapping optionals.