This week in Swift development: the Swift team created several fun new starter tasks, Doug Gregor fixed a nasty bug in Objective-C interop, and the mailing lists were abuzz with several exciting Swift Evolution proposals. Adjust your Apple Watches – it’s “Swift Weekly Brief O’Clock”!
有兴趣赞助 Swift Weekly Brief?点击这里
Starter tasks
- SR-6264: This task is to extract
duplicated code in three methods. The methods each check whether a declaration
may be used externally based on its access level (
public
,internal
, etc.). - SR-6272: This task is to add better
diagnostics for common numerical conversions. For example, the Swift compiler
should be able to suggest a cast for source code that attempts to multiply an
Int
and aCGFloat
. - SR-6312: To clone the apple/swift
family of projects, and to pull in the latest changes to those clones,
contributors use a Python script:
utils/update-checkout --clone
to clone, and justutils/update-checkout
to update. This task is to modifyutils/update-checkout
so that it suggests using--clone
if the user attempts to update before cloning.
If you’re looking for a meatier task, you may want to try SR-3423, which would allow enum cases with tuple raw values. In other words, you could make this possible in Swift:
Submit a task by sending a pull request or opening an issue.
News and community
Arek Holko posted a checklist for diagnosing and improving long compile times in Swift projects.
Brian Gesiak continued his Swift compiler series with An Introduction to the Swift Compiler Driver.
Commits and pull requests
Doug Gregor fixed
an issue in which Swift’s ClangImporter would use a stale AST cache for
properties of Objective-C classes, which affected how declarations would be
imported into Swift. This most likely fixes an issue in which
-[UIView addGestureRecognizer:]
would sometimes be imported as
UIView.add(_:)
.
John McCall added a way to represent coroutines in Swift’s intermediate language, SIL.
Daniel Dunbar opened a pull request that improves the cancellation model in llbuild. Previously, cancelling a build in llbuild would not stop work that was in-flight, but instead merely have those units of work finish normally and then report a “cancelled” status. The change cancels the work, preventing it from completing as it normally would.
Mark Lacey opened a pull request to fix edge cases in which implicitly-unwrapped optional (IUO) usage that was disallowed by SE-0054 was considered valid in Swift 3 and 4. This is a “source-breaking” change for codebases that used syntax that, while being technically invalid in Swift 3 and 4, would not result in errors being emitted by the Swift compiler until now. He also opened a pull request that removes a soon-to-be-disallowed IUO from swift-corelibs-foundation.
Philippe Hausler opened a pull request to update swift-corelibs-foundation with the latest CoreFoundation source code included in macOS High Sierra.
Francis Ricci opened a pull request that allows Objective-C to be imported even on non-Darwin platforms. Although I would imagine almost no developers use an Objective-C runtime outside of Darwin, this does decouple some ClangImporter behavior from its host platform, which seems like a good thing to do.
Proposals in review
The review
of SE-0187:
Introduce Sequence.filterMap(_:)
has begun and runs through November 14th, 2017.
We propose to deprecate the controversial version of a
Sequence.flatMap
method and provide the same functionality under a different, and potentially more descriptive, name. […] The name beingfilterMap(_:)
as we believe it best describes the intent of this function. […] Since the old function will still be available (although deprecated) all the existing code will compile, producing a deprecation warning and a fix-it.
The review
of SE-0188:
Make stdlib index types Hashable
begins now and runs through November 14th, 2017.
This proposal would add
Hashable
conformance to all the index types in the standard library. With that done,[Int]
,String
, and all other standard libary collections would have the same behavior when using subscripts in key paths.
Mailing lists
Tony Parker solicited
public feedback on a Foundation-only proposal that has been evaluated internally
at Apple. The proposal is for a mechanism to encode and decode JSON keys in
order to, for example, automatically deserialize snake_case_keys
as
camelCaseKeys
.
Dave DeLong proposed allowing custom operators to take parameters with default arguments. He also provided an implementation with the proposal.
Ben Cohen pitched
eliminating IndexDistance
from Collection
. He tweeted
that it would make writing generic algorithms easier.
Alejandro Alonso proposed
adding standard library functions for generating random numbers, as well as for
randomizing the order of an array (“shuffling”). The proposal aims to address
a pain point in cross-platform Swift development, since different platforms
use different randomization functions (arc4random()
on Darwin, random()
or
rand()
on Linux, etc.).
Jacob Bandes-Storch re-proposed
adding an allCases
static property to enums. The proposal was widely popular
when it was first proposed for Swift 3, but ultimately deferred. If it’s
accepted this time, we may see it in Swift 5.
Discussion of Graydon Hoare’s Swift Evolution
proposal draft,
which adds a target environment platform condition to the Swift language,
continues. The patch proposes adding a #if targetEnvironment(simulator)
condition. Replies to the proposal began to discuss what attributes should be
available as platform conditions. This week, Graydon pointed out
that whether the compilation target was a simulator or not was encoded in the
target triple, a decision made recently in LLVM, so discussions of whether it
should be encoded at all should be done on the LLVM mailing lists.
Brent Royal-Gordon asked
about how he could update his once deferred proposal, SE-0132,
which proposes renaming several Sequence
and Collection
methods such that
they follow a consistent naming scheme.
Erik Eckstein proposed
deprecating the -Ounchecked
compiler option. This optimization mode removes
runtime safety checks, and adds additional complexity to the standard library
code, which must behave differently at that optimization level.
Rick Ballard responded to questions about SwiftPM’s roadmap for Swift 5.
Kelvin Ma pointed out that Swift has potential to layout some enums using fewer bytes.
Finally
Did you remember to adjust for DST? (That’s “delightful Swift time”, of course.)