Another two weeks have passed since the last issue, and its now May. How time flies! WWDC is creeping up, while the Swift team is still hard at work on Swift 4.2 and Swift 5.
- SR-7559 [Package Manager] Building
rsync, and crashes with an obscure message if not found
News and community
Commits and pull requests
Doug Gregor merged a pull request that lays the groudwork to eliminate
SubstitutionList, the old representation for a mapping of generic parameters to concrete types. To learn more about this, check out this Twitter thread.
The core team has accepted this proposal, with the following revisions:
The method to get a random element from a collection should be named
Collection.randomElement() -> Element?
Since not all platforms will be able to provide an implementation of random that’s a cryptographically secure source of randomness, and that different platforms and users have different priorities, the decision of exactly which implementation to use for the default random number generator will be left to that platform’s implementation of Swift.
The core team decided to keep the proposal’s use of static methods.
The random number generator argument should be taken
The core team accepted one of the two proposed Sequence extensions, with a different name than was proposed:
Proposals in review
This proposal introduces the ability for Swift code to query the in-memory layout of stored properties in aggregates using key paths. Like the
offsetofmacro in C,
MemoryLayout<T>.offset(of:)returns the distance in bytes between a pointer to a value and a pointer to one of its fields.
We propose adding a number of properties to the
Unicode.Scalartype to support both common and advanced text processing use cases, filling in a number of gaps in Swift’s text support compared to other programming languages.
The Swift String type, and related types like
Unicode.Scalar, provide very rich support for Unicode-correct operations. String comparisons are normalized, grapheme cluster boundaries are automatically detected, and string contents can be easily accessed in terms of grapheme clusters, code points, and UTF-8 and -16 code units.
However, when drilling down to lower levels, like individual code points (i.e.,
Unicode.Scalarelements), the current APIs are missing a number of fundamental features available in other programming languages.
Unicode.Scalarlacks the ability to ask whether a scalar is upper/lowercase or what its upper/lowercase mapping is, if it is a whitespace character, and so forth.
This proposal introduces a
compilerdirective that is syntactically equivalent to the
#if swiftversion check but checks against the version of the compiler, regardless of which compatibility mode it’s currently running in.
#if swiftcheck allows conditionally compiling code depending on the version of the language. Prior to Swift 4, the version of the compiler and the language were one and the same. But since Swift 4, the compiler can run in a compatibility mode for previous Swift versions, introducing an new version dimension. To support code across multiple compiler versions and compatibility modes, extra language versions are regularly introduced to represent old language versions running under compatibility mode.
Sequencemodels brings a lot of niceties that we didn’t have access to in Objective-C, like map and filter, there are other useful operations on
Sequences that the standard library doesn’t support yet. I’d like to pitch one today:
count(where:), which counts the number of objects in a Sequence that passes some test.
You can read the proposal here.
The easiest way to see the problem is to define an
@objcprotocol with a closure-taking method:
And then implement that protocol in Objective-C
[..] I see a couple of potential solutions here, which aren’t mutually exclusive:
- Implicitly use
withoutActuallyEscapingwhen calling an
@objcAPI from Swift
- Warn about non-escaping closure parameters in
@objcentry points that can be implemented in Objective-C
Lets open the wound on access control again, shall we? 😂