Issue #94 09 Nov 2017
Written by: Brian Gesiak
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”!
Interested in sponsoring Swift Weekly Brief? Learn more here.
- 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 (
- 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
- 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 --cloneto clone, and just
utils/update-checkoutto update. This task is to modify
utils/update-checkoutso that it suggests using
--cloneif 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:
News and community
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
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.
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
We propose to deprecate the controversial version of a
Sequence.flatMapmethod and provide the same functionality under a different, and potentially more descriptive, name. […] The name being
filterMap(_:)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.
This proposal would add
Hashableconformance to all the index types in the standard library. With that done,
String, and all other standard libary collections would have the same behavior when using subscripts in key paths.
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
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,
rand() on Linux, etc.).
Jacob Bandes-Storch re-proposed
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
which adds a target environment platform condition to the Swift language,
continues. The patch proposes adding a
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.
Becca Royal-Gordon asked
about how she could update her once deferred proposal, SE-0132,
which proposes renaming several
Collection methods such that
they follow a consistent naming scheme.
Erik Eckstein proposed
-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.
Kelvin Ma pointed out that Swift has potential to layout some enums using fewer bytes.
Did you remember to adjust for DST? (That’s “delightful Swift time”, of course.)