Things have been more quiet this week as everyone is excited about Swift 5 development beginning (announced last week). Bugs are being fixed, improvements are being made, and we finally found out where Chris Lattner is headed next!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-5674: Add fix-it for computed let declaration.

Submit a task by sending a pull request or opening an issue.

Swift Unwrapped

Episode 24: ABI Stability - Mangling. Continuing from previous episodes on ABI Stability, this JP and Jesse discuss the mangling component and address some mistakes made in previous episodes.

News and community

Chris Lattner officially announced that he will be joining Google Brain.

Mike Ash wrote a really great Friday Q&A on Swift.Unmanaged, describing the way Swift converts object references to and from raw C pointers. He gives a good overview of this task in general, dividing API usage by memory management requirements, which depends on object ownership. He also provides a few fundamental patterns to use: Synchronous Callback, Asynchronous One-Shot Callback, and Asynchronous Multi-Shot Callback.

Commits and pull requests

String/Substring.CharacterView was marked as deprecated in this pull request from Michael Ilseman. Moving from Swift 3.2 to Swift 4 could be a little bit easier now. “CharacterView is now entirely redundant in Swift 4. Deprecate its use. This also allows us to schedule the unbreaking of String.CharacterView leakiness without a hard source break.”

Arnold Schwaighofer merged a fix for a memory leak in _cocoaStringSlice. (Original fix by John McCall.)

Robert Widmann merged a pull request to resolve an issue (SR-5671) where downcasting inside a switch case from an array of superclass objects to array of subclass objects would fail to compile.

Slava Pestov merged changes to improvement to SIL by recording whether vtable entries are inherited or overridden.

Harlan Haskins merged the initial implementation of the Swift libSyntax API, which was discussed first in Issue #81.

Deyton Sehn fixed SR-5677 to clarify unsupported options passed to swift on the command line where users probably intended to use swiftc.

Accepted proposals

SE-0185: Synthesizing Equatable and Hashable conformance by Tony Allevato was accepted. You can find the implementation here.

Feedback for the feature was glowingly positive, and the proposal is accepted. The core team discussed the concerns raised in the feedback thread for the proposal. Here are some rough notes (not intended to be exhaustive), but it is important to recognize that the proposal follows the design of the auto-synthesized Codable proposal, and that many of these same points were discussed when it came up:

  • The core team feels that adding compiler magic for this case is reasonable because it solves an important user need, and doesn’t preclude the introduction of a more general feature (e.g. like a macro system, or Rust’s ‘deriving’ feature) in the future. When/if that feature is designed and built, the compiler magic can be replaced with standard library magic.

  • The hash value of a type is not intended to be stable across rebuilds or other changes to the code. It is ok to change if fields are reordered, the standard library changes the hash function, etc. Tony pointed this out on-thread, saying: The stdlib documentation for hashValue states “Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.”

  • The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.

Many thanks to Tony Allevato for driving forward this proposal. The patch just needs final code review now - I think we’re all looking forward to this landing, congrats!

Mailing lists

Robert Widmann started a discussion on the swift-dev mailing list to fully remove the SwiftExperimental library. A pull request was opened and is waiting for approval. If you have ideas how to transform SwiftExperimental into something new and useful — don’t be shy!

The SwiftExperimental library’s stated purpose is to be a place where experimental library features could be explored without fear of committing to a stable interface. At least, that was its goal many years ago when significant work on it was last done. Since then, SwiftExperimental has sat untouched except for passing committers that need to alter parts of its implementation for language changes.

I would like to remove this library and target from the project, but first I’d like to solicit opinions about this change. In particular, if there are any users of the library, I’d like to know. I’d also like to know if there would be any interest in reviving a project like this in a different form — ideally out of tree.

Daryle Walker stared a discussion on adding the constexpr facility from C++ to Swift.

The “constexpr” facility from C++ allows users to define constants and functions that are determined and usable at compile-time, for compile-time constructs but still usable at run-time. The facility is a key step for value-based generic parameters (and fixed-size arrays if you don’t want to be stuck with integer literals for bounds). Can figuring out Swift’s story here be part of Swift 5?

Finally

And finally — this is an outrage.