It’s been a while since I last wrote an issue, but I am glad to be writing another one. Especially after meeting JP at FrenchKit where we both gave a talk (JP did one on profiling Swift performance on Linux (slides), I did one on what we can expect from Swift 5 (slides)). There will be videos, but we’ll have to wait a little longer for those.
Other than that, we are now less than a month away from the iPhone X! That means upgrading your apps sooner rather than later.
Have a great week!
有兴趣赞助 Swift Weekly Brief？点击这里
Starter tasks
There’s a starter task to check if a given map file exists when passing it as an argument.
Submit a task by sending a pull request or opening an issue.
Swift Unwrapped
In Episode 31 Jesse and JP discuss compile times, looking at the ways you can profile and improve your compile times and some discussions on the mailing lists regarding the topic.
News and community
Apple open sourced their CoreML tools - and they’re open to contributions. 😱
The Swift HTTP server v0.1.0 is now available! Go try it out and leave some feedback!
Chris Bailey checked the speed of the various Swift HTTP frameworks to check “which is the fastest?”.
Nate Cook wrote a blogpost on the official Swift.org blog talking about the improvements (like SE-0165 and SE-0154) made in Dictionary and Set in Swift 4. It contains some great examples (with emoji 👌).
Ted Kremenek is looking for someone to help him with project management on Swift. Maybe it’s you he’s looking for?! 🏎
Slava Pestov shared that Swift’s 5 goal of ABI stability also means he’s also able to do some cleanup because of it. 💪
Doug Gregor’s improvements on generics sped up the type checking phase of the standard library by a whopping 300%!
Commits and pull requests
Kelvin Ma opened a pull request that has an implementation for his proposal. This implements part of the original proposal, SE-0184.
Doug Gregor implemented one of the two proposals required for ABI stability, SE-0157: Support recursive constraints on associated types. In the process, that removed more than 600 lines of code in the standard library that were not needed anymore. 1 to go!
Roman Levenstein made some progress on ABI stability - as well as cleaning up the compiler. 😎
Jordan Rose opened a pull request on swift-evolution to add non-exhaustive enums to Swift. It (obviously?) includes an implementation too. Read the pitch for this proposal on the mailing lists.
Slava Pestov opened a pull request that fixes a one and a half year old bug related to the use of Self and self.
Robert Widmann opened a pull request to diagnose infinite recursion (recursion, recursion), fixing four SR-bugs in the process.
Accepted proposals
SE-0186: Remove ownership keyword support in protocols was accepted.
Feedback for the proposal — which many interpreted as being mostly a compiler bug fix — was limited but unanimously positive. The consensus was that removing the support for these ownership keywords in protocols removes false expectations on their behavior, which could be a source of bugs.
Mailing lists
Chris Lattner sent out an email discussing a metaproposal - a proposal on a proposal - to tackle refining identifier and operator symbology.
The proposal correctly observes that the partitioning of unicode codepoints into identifiers and operators is a mess in some cases. It really is an outright bug for 🙂 to be an identifier, but ☹️ to be an operator. That said, the proposal itself is complicated and is defined in terms of a bunch of unicode classes that may evolve in the “wrong way for Swift” in the future.
The core team would really like to get this sorted out for Swift 5.
To make progress on this, we suggest a few separable steps:
First, please split out the changes to the ASCII characters to its own proposal [..]
Second, someone should take a look at the concrete set of unicode identifiers that are accepted by Swift 4 and write a new proposal that splits them into the three groups: those that are clearly identifiers (which become identifiers), those that are clearly operators (which become operators), and those that are unclear or don’t matter (these become invalid code points).
Third, if there is interest sometime in the future, we can have subsequent proposals that expand the range of accepted code points, motivated by the specific application domain that cares about them. These proposals will not be source breaking, so they can happen at any time.