Issue #130 21 Mar 2019
Written by: Bas Broek
Last week, Apple announced this year’s WWDC, while Swift is steadily progressing to what’s next after Swift 5.
Skafos is the tool for iOS developers to deploy machine learning to their app. Get started with a pre-trained model, drop in the SDK and then updates are pushed to your app in the background. Sign up for the free beta today.
- TF-336 [Python] Add unit testing infrastructure for Python 2 and 3
- TF-337 [Python]
Sequenceuses array indexing instead of
- TF-342 [Python] Adopt Python iterator C API
- TF-351 [AutoDiff] Fixit
.withoutDerivative()is inserted to the wrong place
News and community
swift-logis only the start of a logging that works across the whole ecosystem.
Commits and pull requests
Eric Eckstein merged a pull request that eliminates memory allocations from code making heavy use of generics, protocols with associated types, conditional conformances and various other language features:
These are temporary allocations made by the Swift runtime, while building type metadata. While in most cases the results are cached and reach a steady state, this will still help startup time. For casts to protocols where the type conditionally conforms, speeds up runtime too.
The proposal is accepted, with a request that the original proposal be amended for clarification of actual behavior. The Core Team felt that the proposal should more explicitly illustrate the actual behavior in a few specific cases, as this was the crux of some of the back-and-forth in the review thread. Note: the proposal has been updated to include more details in the proposed solution section, as requested by the Core Team.
This proposal suggests a new initializer for
ContiguousArraythat provides access to an array’s uninitialized storage buffer.
Some collection operations require working on a fixed-size buffer of uninitialized memory. For example, one O(n) algorithm for performing a stable partition of an array is as follows:
- Create a new array the same size as the original array.
- Iterate over the original array, copying matching elements to the beginning of the new array and non-matching elements to the end.
- When finished iterating, reverse the slice of non-matching elements.
Unfortunately, the standard library provides no way to create an array of a particular size without initializing every element. Even if we avoid initialization by manually allocating the memory using an
UnsafeMutableBufferPointer, there’s no way to convert that buffer into an array without copying the contents. There simply isn’t a way to implement this particular algorithm with maximum efficiency in Swift.
Proposals in review
We propose that the Swift project adopt a set of code style guidelines and provide a formatting tool that lets users easily diagnose and update their code according to those guidelines. These guidelines would not be mandatory for all projects, but encouraged for Swift code to follow for general consistency.
This proposal introduces the ability to use the key path expression
\Root.valuewherever functions of
(Root) -> Valueare allowed.
String and related types are missing trivial and obvious functionality, much of which currently exists internally but has not been made API. We propose adding 9 new methods/properties and 3 new code unit views.
- 6 simple APIs on Unicode’s various encodings
- 2 generic initializers for string indices and ranges of indices
Substring.base, equivalent to
One of the most common API requests from performance-minded users of string is a way to get direct access to the raw underlying code units. Now that Swift 5 uses UTF-8 for its preferred encoding, we can provide this.
“Contiguous strings” are strings that are capable of providing a pointer and length to validly encoded UTF-8 contents in constant time. Contiguous strings include:
- All native Swift string forms
- Lazily bridged Cocoa strings that provide a pointer to contiguous ASCII
- Any “shared string” concept we may add in the future
This proposal introduces two new protocols to the standard library:
Real. These protocols combine to provide “basic math functions” in generic contexts for floating-point and SIMD types, and provide a path to extend that functionality to planned complex types in the future.
BinaryFloatingPoint(and the protocols it refines) provides a powerful set of abstractions for writing numerical code, but it does not include the transcendental operations defined by the C math library, which are instead imported by the platform overlay as a set of overloaded concrete free functions.
String’s ABI encodes information for performant processing and future flexibility, allowing the standard library to run faster and producer smaller and more flexible code. But, this information is not available as API for low-level programming as it’s hidden behind the abstraction of the String type. With this information formally part of
String’s ABI, we should lift the veil of the
Stringtype and start exposing these as API.
The issues this post is concerned with affect enums with multiple cases, one or more of which has a payload. In the Swift compiler enums fitting this description are implemented either as a single-payload enum or a multi-payload enum. A single-payload enum consists of exactly one case with a payload as well as one or more empty cases. Multi-payload enums are any other enum with multiple cases and one or more payloads. In particular, multi-payload enums are used whenever there are multiple cases with payloads regardless of whether the payloads have the same type.
Dynamic member lookup allows a type to opt in to extending member lookup (“dot” syntax) for arbitrary member names, turning them into a string that can then be resolved at runtime. Dynamic member lookup allows interoperability with dynamic languages where the members of a particular instance can only be determined at runtime… but no earlier. Dynamic member lookups therefore tend to work with type-erased wrappers around foreign language objects (e.g.,
PyValfor an arbitrary Python object), which don’t provide much static type information.
[We propose to] introduce a new attribute
@keyPathMemberLookupthat can be placed on the definition of a type. For such types, “dot” syntax to access a member will be rewritten as a use of a special subscript whose argument is a key path describing the member.
I’ve been trying to wrap my head around SE-0244: Opaque Result Types and recently I had some realizations that helped me understand the proposal better. I noticed I’m not the only one confused about it, so I thought I’d write down some things that might help others to get a better grasp of the concept as well.
In doing so, I’d also like to try and rebrand opaque result types, or at least the underlying mechanism, to something I’m calling ‘reverse generics’. I think viewing this all from a slightly different perspective helps a lot in understanding the concepts involved.
Almost all production server software needs to emit metrics information for observability. The SSWG aims to provide a number of packages that can be shared across the whole Swift Server ecosystem so we need some amount of standardization. Because it’s unlikely that all parties can agree on one full metrics implementation, this proposal is attempting to establish a metrics API that can be implemented by various metrics backends which then post the metrics data to backends like prometheus, graphite, publish over statsd, write to disk, etc.
As outlined above, we should standardize on an API that if well adopted would allow application owners to mix and match libraries from different parties with a consistent metrics collection solution.
Swift currently supports marking declarations with attributes, such as
@deprecated. The compiler uses these attributes to change the way it interprets the corresponding code. However, there is no support for declaring and using new attributes to suit the needs of a project or library. This proposal aims to change that.
This proposal introduces callables to Swift. Values that behave like functions can take advantage of this syntactic sugar, to look like a function call when they are called.
In a nutshell, we propose to introduce a new declaration syntax with the keyword
Values that have a call member can be applied like a function, forwarding arguments to the call member.
Ever created a “small” memory leak? 🚰