September is approaching swiftly, which means that we’ll be seeing new iPhones and all the new software before we know it.
And although that won’t yet bring Swift 5, we will get Swift 4.2 that comes with some awesome improvements as well, plus we’ll still have Swift 5 to look forward to!
Starter tasks
- SR-8507 [Compiler] ‘foo bar’ could have fixit suggesting missing
.
rather than just;
or,
- SR-8536 [Compiler] Warn on member assignments capturing
self
- SR-8598 [Compiler] Deprecating then obsoleting can be error prone
Swift Unwrapped
Swift Unwrapped is back from the summer break, and will take on a new format with longer episodes once a month.
In episode 66, Jesse and JP discuss the plan for module stability, outlined by Jordan Rose on the forums.
News and community
Ted Kremenek shared that Swift 4.2 is in final convergence. Not much longer now!
Commits and pull requests
Jordan Rose merged a pull request that adds default argument values in the generated interface view within Xcode. This also closes SR-2608.
Doug Gregor merged a pull request improving name lookup from declaration checking. “With the request evaluator, new function type representation, SubstitutionMap
redesign and removal of curried parameter lists we’re finally paying off a lot of tech debt - the implementation is catching up to the language” 🎉
Greg Titus merged a pull request that ports Optional unwrapping fixits to the new diagnostics framework.
Accepted proposals
SE-0224: Support ‘less than’ operator in compilation conditions was accepted.
The proposal text will be amended to include the mention of the change of behavior to
#if compiler
, which is also reflected in the implementation and logically fits in with this change:The proposal only mentions
#if swift(<4.2)
but the implementation also appears to support#if compiler(<4.2)
from SE-0212.
Returned proposals
SE-0200: Enhancing String Literals Delimiters to Support Raw Text was returned for revision.
Like many computer languages, Swift uses an escape character (
\
) to create a special interpretation of subsequent characters within a string literal. Escape character sequences represent a set of predefined, non-printing characters as well as string delimiters (the double quote), the escape character (the backslash itself), and (uniquely in Swift) to allow in-string expression interpolation.Escape characters provide useful and necessary capabilities but strings containing many escape sequences are difficult to read. Other languages have solved this problem by providing an alternate “raw” string literal syntax which does not process escape sequences. As the name suggests, raw string literals allow you to use “raw” text, incorporating backslashes and double quotes without escaping.
We propose to alter Swift’s string literal design to do the same, using a new design which we believe fits Swift’s simple and clean syntax. This design supports both single-line and multi-line string literals, and can contain any content whatsoever.
Proposals in review
SE-0223: Accessing an Array’s Uninitialized Buffer is under review.
This proposal suggests a new initializer and method for
Array
andContiguousArray
that provide 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 allocating every element, or to copy elements to the end of an array’s buffer without initializing every preceding element.
SE-0225: Adding isEven
, isOdd
, isMultiple
to BinaryInteger
is under review.
This proposal adds
var isEven: Bool
,var isOdd: Bool
, andfunc isMultiple(of other: Self) -> Bool
to theBinaryInteger
protocol.isEven
andisOdd
are convenience properties for querying the parity of the integer andisMultiple
is a more general function to determine whether an integer is a multiple of another integer.
SE-0226: Package Manager Target Based Dependency Resolution is under review.
This is a proposal for enhancing the package resolution process to resolve the minimal set of dependencies that are used in a package graph.
The current package resolution process resolves all declared dependencies in the package graph. Some of the declared dependencies may not be required by the products that are being used in the package graph. For e.g., a package may be using some additional dependencies for its test targets. The packages that depend on this package doesn’t need to resolve such additional dependencies. These dependencies increase the overall constraint in the dependency resolution process that can otherwise be avoided. It can cause more cases of dependency hell if two packages want to use incompatible versions of a dependency that they only use for their unexported products. Cloning unnecessary dependencies also impacts the performance of the resolution process.
Swift Forums
Ankit Aggarwal shared a small proposal regarding tagging and publishing of Swift packages.
Swift packages can be in a bunch of states which makes them inappropriate for tagging or publishing. I think having a command to detect such states would be valuable for Swift package authors. In the future, this can even evolve into a larger tag-and-publish workflow feature.
Greg Titus shared an update on the much improved fixits for Optional chaining and force unwrapping.
[..] The force unwrap fixit still exists, but it is now never the only or preferred fixit offered, and hopefully the explanations of the errors are a lot more beginner-friendly now.
These error messages have been much-improved. I recommend taking a look at the changes yourself.
Ted Kremenek shared they are evaluating implementing the Language Server Protocol in Swift.
[We] have also been recently discussing offline LSP and evaluating potential strategies. We’ll start a thread soon once we’ve put those thoughts in order; should be soon.