Issue #69 11 May 2017
Written by: Jesse Squires
We’re less than a month away from WWDC. While the swift-evolution proposal train seems to finally be slowing down, it seems like the Swift team is just as busy as ever as the end of the Swift 4 release cycle approaches.
Interested in sponsoring Swift Weekly Brief? Learn more here.
Starter tasks
- SR-4827: Incorrect result resolving type for Objective-C block
- SR-4858:
IndexPath.hashValue
broken on Linux - SR-4824: Add tests to check Collection constraints are being enforced
Submit a task by sending a pull request or opening an issue.
Swift Unwrapped
Episode 10: The Variety Show
This week we discuss multi-line strings, reduce with inout, one-sided ranges, and more!
News and community
Sommer Panage discusses how to make writing UI code simpler with Swift in her talk, Writing Your UI Swiftly from try! Swift Tokyo 2017. The video was posted last month, but I’ve finally got around to watching it! It’s really great, I highly recommend it.
Nate Cook also gave a great talk, Swift’s Pointy Bits: Unsafe Swift & Pointer Types, at try! Swift Tokyo 2017. Nate explores and explains what “safety” really means in Swift. Again, this video isn’t extremely new, but I just watched it this week. Awesome talk.
Commits and pull requests
Ben Cohen added Collection
constraints via protocol where clauses requiring Indices
and SubSequence
match the traversal. This resolved 8 ABI FIXMEs!
Robin Kunde merged diagnostic notes and fixits for confusable unicode characters.
John McCall merged refinements to dynamic exclusivity, continuing work outlined in the Ownership Manifesto.
Michael Ilseman implemented support for Unicode 9 grapheme breaking (i.e. emoji). Whatever that means. 😆
Jordan Rose opened a pull request to make all CoreFoundation types conform to Equatable
and Hashable
using CFHash
and CFEqual
as the implementation. This will be available in Swift 4, even when using “Swift 3 mode”.
Erik Eckstein merged changes to allow Character
literals that fit into 64 bits, be folded into a single integer constant. It makes character literals much faster (3x improvement for the CharacterLiteralsSmall benchmark) and it removes a lot of redundant code (~80% for the CharacterLiteralsSmall benchmark).
Accepted proposals
SE-0174: Change filter
to return an associated type was accepted.
The proposal is accepted. Thank you to everyone who participated in the review!
SE-0175: Package Manager Revised Dependency Resolution was accepted.
The proposal is accepted for Swift 4. Thank you to everyone who participated in the review!
Mailing lists
Ben Cohen pitched a draft proposal to add a unicodeScalar
view to Character
, similar to that on String
.
The
Character
element type ofString
is currently a black box that provides little functionality besides comparison, literal construction, and to be used as an argument toString.init
.Many operations on String could be neatly/readily implemented as operations on each character in the string, if
Character
exposed its scalars more directly. Many useful things can be determined by examining the scalars in a grapheme (for example is this an ASCII character?).
Finally
And finally — ambiguous use of ‘abs’.