Issue #116 23 Aug 2018
Written by: Bas Broek
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!
- SR-8507 [Compiler] ‘foo bar’ could have fixit suggesting missing
.rather than just
- SR-8536 [Compiler] Warn on member assignments capturing
- SR-8598 [Compiler] Deprecating then obsoleting can be error prone
Swift Unwrapped is back from the summer break, and will take on a new format with longer episodes once a month.
News and community
Commits and pull requests
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” 🎉
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.
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
This proposal suggests a new initializer and method for
ContiguousArraythat 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.
This proposal adds
var isEven: Bool,
var isOdd: Bool, and
func isMultiple(of other: Self) -> Boolto the
isOddare convenience properties for querying the parity of the integer and
isMultipleis a more general function to determine whether an integer is a multiple of another integer.
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 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.
[..] 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.
[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.