This week two more outstanding proposals were formally accepted, including the much anticipated String Newline Escaping proposal, and there was a new, last minute string performance proposal from Ben Cohen. Even more, two non-Apple contributors have stepped up to implement two accepted-but-unimplemented proposals. Keep in mind, we’re already on beta 3 of Xcode 9 so the clock is ticking! Unfortunately, the time is up for some. Joe Groff confirmed that conditional conformances will not make the cut for Swift 4 (sad!), but he made up for the bad news by revealing how dogs wear pants. And yes, this means Joe is back from his Twitter hiatus!

Swift Unwrapped

In Episode 20: Swift Migrator, we dissect the newly open sourced part of Swift tooling that helps us port our apps to the latest Swift version.

News and community

Mike Ash is back with another Friday Q&A on Swift.Codable. Mike’s Friday Q&A posts are always spectacular. 🙌

Tom Lokhorst wrote a great post on Strongly typed identifiers in Swift. This is a clever way to take advantage of the type system instead of relying on traditional string identifiers or a mere typealias. I will definitely be implementing this in my projects!

Unfortunately, it looks like conditional conformances (SE-0143) are not going to happen for Swift 4 / Xcode 9. The proposal was accepted for Swift 4, but has not been completed. Maybe we’ll see this in a future Swift 4.1 release? At least we got multi-line strings though, am I right? 😉

Commits and pull requests

Doug Gregor merged a pull request enabling recursive protocol constraints by default (SE-0157). However it was later reverted.

John Holdsworth implemented String newline escaping, SE-0182.

Jordan Rose opened a pull request that adds documentation describing the Swift, LLVM, and LLDB branch structure. Super helpful!

The great David Rönnqvist (@davidronnqvist) implemented reduce with inout, SE-0171.

Slava Pestov fixed a bug with capture analysis for defer. “A ‘defer’ that uses generic parameters inside of a closure had incorrect capture info computed by Sema, which could trigger various SILGen assertions.”

Itai Ferber fixed a few outstanding issues with the new Codable protocol. (SR-4772 and SR-5122)

Accepted proposals

SE-0181: Package Manager C/C++ Language Standard Support was accepted with revision.

There was support for the general feature, with some discussion of the spelling. We chose to accept the proposal mostly unmodified:

1. While we agreed the enum cases could have simpler spellings, we felt this would require substantial design with little practical benefit (at this time, we will consider this for our future build setting proposal).
2. We agreed with feedback that using cLanguageStandard, etc in place of cStandard was more consistent, and will adopt that revision.

SE-0182: String Newline Escaping was accepted.

Feedback for the feature was positive, and the proposal is accepted with revision based on community discussion.

The core team requests that the feature be restricted to multi-line string literals, so it is a compile-time error to use in a single-quoted string. As was pointed out during review discussion, enabling escaped newlines for single line strings means that they are not single line anymore, and enabling single quoted strings to span multiple lines does not solve a strongly motivated glaring problem, since they can be upgraded to triple quoted strings. This change reduces the scope of the proposal, allowing proponents of this to restart the discussion later if and when there is compelling evidence (e.g. specific important use cases) to reconsider.

The core team also discussed feedback about the whitespace rules proposed, and agreed with the proposed design. It also discussed whether \ should be allowed on the line immediately following the close """ and agreed that it was best to not allow it in this go-around.

Thank you to John Holdsworth, David Hart, and Adrian Zubarev for driving this proposal forward. Please revise the proposal, and if an adjusted PR can be made soon, we can get it in for Swift 4. Thanks!

Proposals in review

SE-0183: Substring performance affordances by Ben Cohen is under review.

From the email:

Context: One more small refinement proposal for Swift 4 strings. We are specifically not opening the floodgates for new proposals yet, this is this simply one potential small-scope refinement to an existing Swift 4 feature.

From the proposal:

This proposal modifies a small number of methods in the standard library that are commonly used with the Substring type:

• Modify the init on floating point and integer types, to construct them from StringProtocol rather than String.
• Change join to be an extension where Element: StringProtocol
• Have Substring.filter to return a String

[…]

Mailing lists

Kelvin Ma proposed a draft proposal to improve Swift pointers. More specifically, he wants to address inconsistency and improve the convenience of the Unsafe*Pointer APIs. Dave Abrahams and Michael Ilseman expressed support for the idea, though a formal proposal will need more work. You can find the draft in this gist.

Swift currently offers two sets of pointer types — singular pointers such as UnsafeMutablePointer, and vector (buffer) pointers such as UnsafeMutableBufferPointer. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement Collection conformance, while singular pointers do not.

However, some aspects of the pointer design contradict these implied roles. It is possible to allocate an arbitrary number of instances from a type method on a singular pointer, but not from a buffer pointer. The result of such an operation returns a singular pointer, even though a buffer pointer would be more appropriate to capture the information about the number of instances allocated. It’s possible to subscript into a singular pointer, even though they are not real Collections. Many of the memorystate methods on UnsafeMutablePointer work on vectors of items, while others, such as move() return a single instance. Some parts of the current design turn UnsafePointers into downright DangerousPointers, leading users to believe that they have allocated or freed memory when in fact, they have not.

This proposal seeks to iron out these inconsistencies, and offer a more convenient, more sensible, and less bug-prone API for Swift pointers.

Finally

And finally — the truth about how dogs wear pants.