In the last two weeks, a lot about Swift has been discussed. Proposals, ideas, improvements, and updates galore.
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-67 [Autodiff]
BumpPtrAllocatingsome classes that have
- TF-86 [Tests] Use
- TF-93 [Graph Program Extraction] Deabstraction should properly diagnose recursion
- TF-130 [Graph Program Extraction] Add API to serialize a
@convention(tensorflow)function as a graph
Jesse and JP talk about the pitch for an official style guide & formatter for Swift.
News and community
Swift 4.2.3 for Linux was released!
The Server Side Swift Conference posted all its videos from their latest event.
Ray Wenderlich created an overview of Server Side Swift resources.
Swift will once again participate in the Google Summer of Code project this year.
Proposals in review
Stringtype is designed for Unicode correctness and abstracts away the underlying binary representation of the string to model it as a
Collectionof grapheme clusters. This is an appropriate string model for human-readable text, as to a human reader, the atomic unit of a string is (usually) the extended grapheme cluster. When treated this way, many logical string operations “just work” the way users expect.
However, it is also common in programming to need to express values which are intrinsically numeric, but have textual meaning, when taken as an ASCII value. We propose adding a new literal syntax takes single-quotes (
'), and is transparently convertible to Swift’s integer types. This syntax, but not the behavior, will extend to all “single element” text literals, up to and including
Character, and will become the preferred literal syntax these types.
This proposal introduces the ability to hide the specific result type of a function from its callers. The result type is described only by its capabilities, for example, to say that a function returns a
Collectionwithout specifying which specific collection. Clients can use the resulting values freely, but the underlying concrete type is known only to the implementation of the function and need not be spelled out explicitly.
After the Swift/Win32 post, I figure that some people may be curious as to the actual state of Swift for Windows. Well, I would like to share a small status update to that end.
This has been a rather interesting and fun journey. I feel that up until this point, we have been making progress, but the surface area is pretty high, particularly for a single person to take on. I have been chipping away at this for a while now. However, as of today, I think that the situation is about to change. I have finally managed to get the compiler, the support libraries, the runtime, standard library, libdispatch, and now, Foundation to build and run on Windows!
Awesome work! 🎉
Swift’s notation for generic constraints generally requires naming the things being constrained; you say that a particular generic parameter conforms to a protocol by naming the generic parameter and the protocol it conforms to, like
<C: Collection>, and you put further constraints on its associated types by naming them in a where clause, like
C.Element: Equatable. However, opaque result types, generalized existentials, and other conceivable future language features need a way to describe constraints on a type that doesn’t otherwise have a name; an opaque type is intentionally hidden from the interface, and an existential’s contained type is dynamic and can change at runtime. I can see this evolving into its own major design discussion so I figured it’s a good idea to spin this off from the initial opaque result types proposal.
To kick things off, I’d like to suggest borrowing another idea from Rust here: In Rust, you can use
T: Trait<Assoc = Type>as shorthand for a combined constraint that
T.Associs same-type-constrained to
Type, as if you’d written
T: Trait where T.Assoc = Type. This shorthand can also be used in Rust’s equivalents of opaque types (
impl Trait<Assoc = Type>) and existentials (
dyn Trait<Assoc = Type>) in addition to generic type constraints. If we were going to do something similar for Swift, we could generalize it a bit so that the shorthand can be used for both protocol and same-type constraints on associated types and to allow constraints between associated types. The result might look something like this:
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.
At the time of this writing, there is no single style agreed on by developers using Swift. Indeed, even Apple’s own Swift projects on GitHub—such as the standard library, Foundation, Swift NIO, and so forth—have adopted their own varying styles. Furthermore, in many cases the code in those projects—despite the owners’ best efforts—is not always completely consistent in terms of style.
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.
Having released Swift 4.2.3, the February 2019 release where we could land a good number of fixes, we’re now happy to open the development of Swift 4.2.4 for Linux.
The Swift team has a new emotional support dog! 🐶