What’s better than one issue of Swift Weekly Brief? Two, of course! My apologies for the confusion and bugs with the mailing list this week! Things are back on track now. So enjoy this special Friday edition!
有兴趣赞助 Swift Weekly Brief?点击这里
Swift Unwrapped
Episode 11: Ownership Manifesto
This week we dive into the Ownership manifesto and give a brief overview of the complex topic of memory ownership revisions currently underway.
News and community
Benjamin Encz wrote an article on implementing an undo/redo stack in Swift using value types as an alternative to NSUndoManager
.
Commits and pull requests
Tony Allevato has opened a pull request to synthesize Equatable
and Hashable
for complex enums and structs. This is the implementation for his yet-to-be-reviewed draft proposal. This would reduce common Equatable
and Hashable
conformance code that developers must routinely write. It’s not clear if this will make it into Swift 4 as the proposal hasn’t even been assigned an SE number.
Slava Pestov fixed a 3-year-old bug (SR-349) with 20 dupes. (PR #9765)
Not only was SE-0178 reviewed and accepted, but also already implemented by Dave Abrahams.
Itai Ferber merged changes to add Codable
conformance to common Foundation types. This work is for proposals SE-0166 and SE-0167.
Accepted proposals
SE-176: Enforce Exclusive Access to Memory was accepted pending revision review.
This proposal has been accepted with revisions. Feedback was strongly positive. Some participants raised concern about the overhead of dynamic checking. The core team shares this concern but feels that there will be adequate opportunities later to make pragmatic decisions about when to enable dynamic checking.
Most of the proposal is accepted. An implementation issue has been discovered with the use of dynamic enforcement on inout parameters. The proposal implementors suggest adopting a stronger rule governing the use of non-escaping closures which will also allow Swift to make firm guarantees about the use of static enforcement when a variable does not escape. The core team tentatively supports this new rule but believes it is a substantial enough revision that it requires a separate review period.
SE-0178: Add unicodeScalars
property to Character
was reviewed:
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/readably implemented as operations on each character in the string, ifCharacter
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?).
And accepted:
The proposal is accepted without revision. The proposal was uncontentious both on swift-evolution and in the Core Team review.
Proposals in review
SE-0163: String Revision: Collection Conformance, C Interop, Transcoding by Ben Cohen and Dave Abrahams is under review.
This proposal is to implement a subset of the changes from the Swift 4 String Manifesto.
Specifically:
- Make
String
conform toBidirectionalCollection
- Make
String
conform toRangeReplaceableCollection
- Create a
Substring
type forString.SubSequence
- Create a
StringProtocol
protocol to allow for generic operations over both types.- Consolidate on a concise set of C interop methods.
- Revise the transcoding infrastructure.
- Sink Unicode-specific functionality into a
Unicode
namespace.Other existing aspects of
String
remain unchanged for the purposes of this proposal.
As mentioned above, SE-176: Enforce Exclusive Access to Memory was accepted pending revisions. A new review period for only the revisions has started:
Most of this proposal was previously accepted. An implementation issue has been discovered with the use of dynamic enforcement on inout parameters. The proposal implementors suggest adopting a stronger rule governing the use of non-escaping closures which will also allow Swift to make firm guarantees about the use of static enforcement when a variable does not escape. The core team tentatively supports this new rule but believes it is a substantial enough revision that it requires a separate review period.
SE-0179: Swift run
Command by David Hart is under review.
The proposal introduces a new
swift run
command to build and run an executable defined in the current package.It is common to want to build and run an executable during development. For now, one must first build it and then execute it from the build folder.
To improve the development workflow, the proposal suggests introducing a new first-level
swift run
command that will build if necessary and then run an executable defined in thePackage.swift
manifest.
Mailing lists
Ole Begemann shared a Swift playground that he created to show off the new features in Swift 4. Get it here.
The playground requires Swift 4 (duh!). You need to install the latest Swift 4.0 snapshot from https://swift.org/download/#snapshots and, after installing it, select the toolchain in Xcode.
I plan to keep the playground updated over the summer as more features get implemented.
This is such a great idea and such an easy way to experiment with unreleased versions of Swift.
Finally
And finally — Apple Smack Us.