4

Issue #108

 2 years ago
source link: https://swiftweeklybrief.com/issue-108/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Issue #108 03 May 2018

Written by: Bas Broek

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.

Starter tasks

  • SR-7559 [Package Manager] Building swiftpm requires rsync, and crashes with an obscure message if not found

Submit a task by sending a pull request or opening an issue.

Swift Unwrapped

In episode 55, Jesse and JP discuss SE-0202, Random Unification.

In episode 56, Jesse and JP discuss SE-0206, Hashable Enhancements.

News and community

Paul Hudson created a website to show a nice overview of what’s new in Swift, browsable by version!

Mark Lacey wrote a blog post on the official Swift blog, dicussing the reimplementation of Implicitly Unwrapped Optionals.

Google announced Tensorflow for Swift. To learn more about it, check out the Design Overview.

Commits and pull requests

Michael Ilseman merged a pull request that removes some @inline annotations, speeding up the compiler.

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.

Pavel Yaskevich merged a pull request that improves exhaustiveness checking in switches.

Accepted proposals

SE-0202: Random Unification was accepted with revisions.

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 inout.

SE-0207: Add a containsOnly algorithm to Sequence was accepted with revisions

The core team accepted one of the two proposed Sequence extensions, with a different name than was proposed:

extension Sequence {
  /// Returns a Boolean value indicating whether every element of the sequence
  /// satisfies the given predicate.
  func allSatisfy(_ predicate: (Element) throws -> Bool) rethrows -> Bool
}

Proposals in review

SE-0210: Add an offset(of:) method to MemoryLayout is under 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 offsetof macro 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.

SE-0211: Add Unicode Properties to Unicode.Scalar is under review.

We propose adding a number of properties to the Unicode.Scalar type 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 Character and 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.Scalar elements), the current APIs are missing a number of fundamental features available in other programming languages. Unicode.Scalar lacks 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.

SE-0212: Compiler Version Directive is under review.

This proposal introduces a compiler directive that is syntactically equivalent to the #if swift version check but checks against the version of the compiler, regardless of which compatibility mode it’s currently running in.

The #if swift check 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.

Swift Forums

Soroush Khanlou pitched a proposal to add count(where:) to Sequence.

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. 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.

Doug Gregor wrote a request for discussion regarding an issue with non-escaping closure parameters can escape through Objective-C.

The easiest way to see the problem is to define an @objc protocol with a closure-taking method:

@objc protocol Fooable {
  func foo(completion: () -> Void) // note: closure parameter is implicitly '@noescape'
}

func useFooable(fooable: Fooable, completion: () -> Void) {
  fooable.foo(completion: completion)
}

And then implement that protocol in Objective-C

@interface MyClass : NSObject <Fooable>
@end

@implementation MyClass
- (void)fooWithCompletion:(void (^)(void))completion {
  dispatch_async(dispatch_get_main_queue(), completion); // oops, we escaped a no-escape block!
}
@end

[..] I see a couple of potential solutions here, which aren’t mutually exclusive:

  • Implicitly use withoutActuallyEscaping when calling an @objc API from Swift
  • Warn about non-escaping closure parameters in @objc entry points that can be implemented in Objective-C

Thoughts?

Finally

Lets open the wound on access control again, shall we? 😂


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK