Issue #119 04 Oct 2018
Written by: Bas Broek
We’re very happy to re-introduce the newsletter’s mail subscriptions, so that you can once again receive Swift Weekly Brief in your inbox. If you haven’t yet and are interested, you can subscribe here.
Enjoy the newsletter and have a great weekend and week!
On November 2 come join us for Do iOS. This is its third edition. Now fully owned and ran by the Dutch CocoaHeads Foundation. Come and join 130 fellow iOS developers for a day filled with content. Come and meet your fellow iOS developers.
There is also a University Day available on November 1.
More info and tickets on
- SR-8703 [Tensorflow] Deabstraction should properly diagnose recursion
- SR-8706 [Compiler] Fix up
parseDependencyFileto not crash on invalid YAML
- SR-8707 [Compiler] Write out swiftdeps files atomically
- SR-8720 [Package Manager] Add –hide-build option to
News and community
Commits and pull requests
The core team has resolved to change the status of this proposal to accepted with modification, deferring the
.isEmojiproperty to a later proposal.
The core team still believe it is a useful feature for the standard library, but needs more investigation that should not hold up the rest of this proposal.
In addition, the proposal will drop the source-breaking change to the existing
FixedWidthInteger.init?. While this would be the preferred naming for a newly proposed initializer, it doesn’t clear the bar for a source-breaking change for Swift 5.
Feedback was overwhelmingly positive, and the proposal is accepted with one small amendment to provide a default implementation of
init(stringLiteral:)for types that conform to
Proposals in review
This proposal would expose a common subset of operations on the SIMD types supported by most processors in the standard library. It is based on Apple’s
<simd/simd.h>module, which is used throughout Apple’s platforms as the common currency type for fixed-size vectors and matrices. It is not a complete re-implementation; rather it provides the low-level support needed to import any such library, and tries to make a number of things much nicer in Swift than they are in C or C++.
try?statement currently makes it easy to introduce a nested optional. Nested optionals are difficult for users to reason about, and Swift tries to avoid producing them in other common cases.
This document proposes giving
try?the same optional-flattening behavior found in other common Swift features, to avoid the common occurrence of a nested optional.
It’s currently quite easy to end up with a nested
Optionaltype when using
try?. Although it is valid to construct a nested optional, it is usually not what the developer intended.
Alejandro Alonso pitched a proposal to make it easier to have default implementations in protocols, without the need of an extension.
I’ve been working on implementing Default Implementation in Protocols and I have a working early implementation of the feature.
What this feature allows is that you can now declare a default implementation of a requirement from the protocol:
Peter Camb shared an issue, which is a bug in Swift that can currently not be solved through Swift iself.
I’m hitting this issue in my NSOpenSavePanelDelegate in a Sandboxed Mac app.
I need to get a reference to the sender as a Panel and set the directory.
All of my
as?casts fail because the Sandbox uses a private subclass for these items.
This is a longstanding bug, but it looks like we don’t have a JIRA bug for it. [..] it’s very similar to SR-5475 (which is about optional properties of protocols). I don’t think we have a good workaround other than defining a little static inline function in Objective-C that will do the call for you without trying to check anything.
An alternate approach in this specific case would be to file a bug against Apple that the sender here is not an instance of
NSOpenPanelor at least
Making all sorts of progress on variadic generics. 🦄