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!
Contribute to Open Source Swift. Get the latest scoop from the founder of RxSwift. Master the new Swift 4 Codable. Build your first ARKit app. Add Machine Learning to your iOS App. Switch to Swift on the Server-Side with the creator of Vapor. Go bowling with new friends!
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
Jordan Rose opened a pull request that adds documentation describing the Swift, LLVM, and LLDB branch structure. Super helpful!
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.”
There was support for the general feature, with some discussion of the spelling. We chose to accept the proposal mostly unmodified:
- 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).
- We agreed with feedback that using
cLanguageStandard, etc in place of
cStandardwas more consistent, and will adopt that revision.
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
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
- Modify the
initon floating point and integer types, to construct them from
jointo be an extension
where Element: StringProtocol
Substring.filterto return a
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
Pointer. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement
Collectionconformance, 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
UnsafeMutablePointerwork 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.
And finally — the truth about how dogs wear pants.