Hello again! 👋 This week Apple announced the WWDC 2018 which will be held from June 4-8 in San Jose, CA. Doug Gregor and Ben Cohen discussed some insights on the Swift 4.1 release on Swift Unwrapped.
Starter tasks
- SR-7083 [Compiler]
lazyproperties can’t have observers - SR-7053 [Package Manager] SwiftPM command line autocompletion script for
zshproduces error: “invalid option definition:…” on completion - SR-7015 [Compiler] The CoreFoundation conditional downcast diagnostic is not as helpful as it should be
- SR-6982 [Compiler] Improve internal compiler consistency
Submit a task by sending a pull request or opening an issue.
Swift Unwrapped
50: Swift 4.1 with Doug and Ben (part 1): Jesse and JP discuss Swift 4.1 with Ben Cohen and Doug Gregor from the Swift team.
News and community
Ted Kremenek shared some insights on the release plan for Swift 5: the expected release date right now is Late 2018.
Slava Pestov shared how seemingly similar code (nil versus .none) can have a big effect under the hood when it comes to code generation.
Erica Sadun wrote a blog post on “Swift Evolution and Civility” regarding the controversy of accepting SE-0199: Adding toggle to Bool. Be nice!
Commits and pull requests
Karoy Lorentey merged a pull request which made Swift use a much higher-quality hashing with random seeding. You can read about this change on the Swift Forums.
“Random seeding” means that
hashValueproperties will return different values on each execution of a Swift program. This is an important tool for improving the reliability of the Standard Library’s hashing collections,SetandDictionary. In particular, random seeding enables better protection against (accidental or deliberate) hash-flooding attacks.
Joe Groff merged a pull request that made generic parameter counts in context descriptors 16-bit from 32-bit, reducing the metadata.
Doug Gregor opened a pull request that further implement generic typealiases. It will be completed once Slava Pestov’s pull request has been merged too.
Slava Pestov merged a pull request that cleans up the @noescape closure implementation in the Swift Intermediate Language (SIL).
Accepted proposals
SE-0194 Derived Collection of Enum Cases was accepted with revisions.
The proposal is accepted with revisions. The specific changes to the proposal as reviewed are:
@objcenums defined in Swift will receive automatic synthesis of the list of all cases. […]- Unavailable cases will not be listed, because values of an unavailable case cannot exist in a well-typed Swift program (in breaks the availability model).
- Automatic synthesis is only provided when the conformance is stated on the enum definition (not an extension) [… ]
- The protocol, associated type, and property are named
CaseIterable,AllCases, andallCases, respectively. The core team felt that these names reflect the primary use case of this protocol, promoting better clarity for most code that iterates over all of the cases. We choseIterableoverEnumerablebecauseEnumerablehas some incorrect connotations (e.g., theenumerated()method).
Proposals in review
SE-0193: Cross-module inlining and specialization is under extended review.
This proposal will essentially be accepted as is — except for the name for
@abiPublic. Many people voiced concern for this name. While it technically is accurate, it exposes the term “abi” which will be foreign to many. It also doesn’t connote the full implications and value of adding the attribute.
SE-0192: Non-Exhaustive Enums is in re-review.
The second review is a follow up to the original review based on feedback on the thread and from the Core Team.
Swift Forums
Chris Lattner shared some insights on the plans to standardize the Result type in Swift — and why it may still take some time.
I personally think it is time to standardize Result, and I believe that several other core team members feel the same way. The major problem with doing so is that is blocked by an unresolved disagreement (in both the core team and community): whether Swift should support typed errors.
Ankit Aggarwal & Daniel Dunbar proposed Package Manager Extensible Build Tools. This will allow community build tools (Sourcery, SwiftLint, Jazzy, etcetera) to integrate with the Swift Package Manager. You can contribute & follow the discussion on the Swift Forums.
This is a proposal for adding package manager support for extensible build tools, i.e. executing tools at build time which were themselves produced by some other package, and whose behavior the package manager does not understood directly, but rather interacts through a well-defined, Swift, protocol.
We expect this behavior to greatly enhance our capacity for building complex software packages.
Graydon Hoare wrote about a new compilation mode called “batch” or “multiple file” mode. There are instructions to try it out in the post.
This new mode takes the set of files that would normally be (incrementally) compiled with individual subprocesses, and assigns them dynamically to multiple batches (one per core), compiling each batch with a single process. This means that incremental mode is still operative, and compilation makes use of multiple cores, but the benefits of whole-module mode (fewer processes, less redundant work) also apply.
Erica Sadun pitched and opened a pull request to propose an “Unwrap-or-Die operator”.
Using an operator to provide feedback on the context of a failed unwrap has become a commonly implemented approach in the Swift developer Community. What are your thoughts about adopting this widely-used operator into the standard library?
guard !lastItem.isEmpty else { return }
let lastItem = array.last !! "Array must be non-empty"Stephen Celis shared some thoughts on when a function can/should crash.
For example:
Dictionary.init(uniqueKeysAndValues😃crashes on duplicate keys. While I can understand the reasoning to throw somehow on a collision, nothing about the name makes it feel “unsafe.” I’d hope the type system would have my back and usethrowsfor these kinds of things.