A calm week during these warm two summer weeks. Nevertheless, here is a quick update on what has happened these weeks.

Starter tasks

• SR-8467 [Compiler] Invalid read when calling swift::AnyFunctionType::getExtInfo
• SR-8464 [Compiler] Attempting to print a function should require the use of String(describing:)
• SR-8453 [Compiler] Warn when redundant access modifier is added in an extension

Swift Unwrapped

While Jesse and JP are on a holiday break from the podcast, you can find all previous episodes here.

News and community

Nicole Jacque shared that Swift 4.1.3, with a Linux-only fix, has been released.

Commits and pull requests

Slava Pestov merged a pull request getting rid of redundancy in protocol derivation.

Philippe Hausler merged a pull request to fix ambiguous mapping to Data from a byte sequence in Swift 4.2.

David Hart merged a pull request that allows SwiftPM to use llbuild as a library, which will “enable great new features and enhancements in the future”.

Pavel Yaskevich merged a pull request to emit diagnostics directly from the constraint solver, moving away from re-type checking sub-expressions after a failure, which has been a source of misleading diagnostics and crashes.

Accepted proposals

SE-0221: Character Properties was accepted with pending discussion.

SE-0221 has been accepted, with the exception of the .isEmoji property.

The core team accepts the principle for the isEmoji property, but wants to continue the discussion of exactly how it should work. Therefore the thread will remain open for this specific topic through August 10th. The other functionality can be merged into master in the meantime.

Proposals in review

SE-0220: count(where:) is under review.

While Swift’s Sequence models 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. One current missing operation is count(where:), which counts the number of elements in a Sequence that pass some test.

SE-0222: Lazy CompactMap Sequence is under review.

Chaining multiple .map()s and .filter()s on a lazy collection leads to suboptimal codegen, as well as large, painful type names.

To improve this, we propose adding a LazyCompactMap{Sequence, Collection} type along with some overloads on the other lazy collection types’ .map(_:) and .filter(_:) functions which return this type to get better codegen and shorter type names.

Swift Forums

Brent Royal-Gordon pitched a proposal to fix String interpolation in Swift 5.

String interpolation is a simple and powerful feature for expressing complex, runtime-created strings, but the current version of the ExpressibleByStringInterpolation protocol has been deprecated since Swift 3. We propose a new design which improves its performance, clarity, and efficiency.

Erica Sadun pitched a proposal to support repeating initializers with closures.

I’d like to pitch a protocol that supports repeated initializers, both for a repeated element and for () -> Element. The goal is to ensure that any type that conforms to the protocol guarantees that if you can initialize with n copies of a value type, then you can initialize with n instances of a reference type or n applications of a closure:

protocol RepeatingInitializable: Collection {
  
  /// See also: `Repeat.swift`: A collection whose elements are all identical.
  /// https://github.com/apple/swift/blob/master/stdlib/public/core/Repeat.swift
  public init(repeating repeatedValue: Element, count: Int)
  
  /// Allow reference types to generate new instances and value types
  /// to use a closure to create potentially distinct values
  ///
  /// A collection whose elements are all created by an identical generator
  public init(repeating repeatedGenerator: @autoclosure () -> Element, count: Int)
}

Finally

When you try to run Swift locally…