It’s already the middle of summer and lot of people are having summer break. Despite that, the Swift team and community members have been active as always. A lot of important pull requests have been merged and created. Not mentioning a lot of active discussions on the forums.
Sponsored Link
SwiftFest Boston 2019, all the talks are live!
SwiftFest is the most community-driven conferences focused on Swift that brings together engineers, architects, midnight-coders, and students in a highly social and vibrant environment. This year you can learn about Swift, SwiftUI, augmented and virtual reality, accessibility, NFC, machine learning, development-culture, security, TDD, etc.
SwiftFest Boston - July, 29th-30th, get your discounted ticket today ($99 off) using the code Swift-Weekly-99-Off.
Starter tasks
- SR-11066 [Compiler] False positive “never mutated” warning when property with mutating getter is accessed on value
- SR-11033 [Compiler] Add option in Swift driver to disable color diagnostics
- SR-10979 [Compiler] Add FixIt for “Operator implementation without matching operator declaration”
Podcasts
In the latest Swift by Sundell episode, John Sundell and Chris Lattner talked about Swift’s past, present and future.
Property Wrappers are becoming an important topic in the Swift community. That’s why JP and Jesse are discussing that in the latest Swift Unwrapped podcast episode.
News and community
Jeremy Howard and Chris Lattner shared a blog post about releasing Swift for TensorFlow v0.4.
Artem Redkin and other contributors released AsyncHTTPClient version 1.0.0-alpha.1 - a Swift NIO2 based HTTP client recently approved to ‘sandbox’ by the Swift Server Work Group.
Swiftbrew - Homebrew for Swift packages 0.1.1 has been released. A package manager that installs prebuilt Swift command line tool packages, or Homebrew for Swift packages.
Argyrios Kyrtzidis pushed a first commit to the Swift Format repository. Swift-format provides the formatting technology for SourceKit-LSP and the building blocks for doing code formatting transformations.
Commits and pull requests
Jordan Rose merged a pull request showing ‘some’ type origins in diagnostics, like ‘aka’ for sugared types.
Pavel Yaskevich merged a pull request that resolves SR-10987: Compiler crashes on invalid reference to subscript
member.
Doug Gregor merged a pull request which allows property wrapper types to support a second access pattern for instance properties of classes.
John McCall merged a pull request that adds support for opaque result types when applying a function builder to a function.
Scott Perry merged a pull request that dramatically improves the runtime performance of collection diffing.
Xiaodi Wu merged a pull request that helps to reorganize Decimal.swift
, aligning two implementations. This resolves SR-3126.
Scott Perry merged a pull request that adds CollectionDifference.inverse()
and test coverage.
John McCall merged a pull request which fixes mangling dependent protocol conformances.
Accepted proposals
SE-0258: Property Wrappers was accepted with modifications.
There was a lot more great discussion in this review, and while there were some questions and reservations, overall the community expressed strong support for accepting the proposal. The Core Team agrees and has decided to accept SE-0258 with only one minor change: we would like to accept the community’s suggestion that the initialValue: argument label on wrapper initializers be renamed to wrappedValue: to match the property name. The Core Team feels that this is a minor enough change to make without a further round of review.
Proposals in review
SE-0261: Identifiable Protocol is under review.
This proposal introduces an
Identifiable
protocol, a general concept that is broadly useful - for diff algorithms, user interface libraries, and other generic code - to correlate snapshots of the state of an entity in order to identify changes. It is a fundamental notion that deserves representation in the standard library.Swift-evolution thread: Move SwiftUI’s
Identifiable
and related types into the standard library
Swift Forums
Johannes Weiss shared meeting notes from the June 27th Swift Server Working Group meeting.
- summary: there are no good solutions so we need a compromise
- we might be overthinking the problem but existing clashes have shown how hard it is to unbreak a clash
- after a lot of discussion we came to the conclusion that ‘despite nobody liking cutesy names very much there are the most lightweight workable solution’. However we won’t prescribe cute names
- try to stay unique, cutesy/clearly unique name preferred for the time being
Argyrios Kyrtzidis explained about plans to integrate libSyntax into the compiler pipeline.
We have been developing libSyntax (and SwiftSyntax as the Swift counterpart) whose purpose is to represent the syntax of Swift source code with full fidelity (including whitespace), enable structured editing, provide immutable, thread-safe data structures, and support incremental re-parsing.
Anthony Platanios started a discussion about removing the Comparable
constraint for Numeric.Magnitude
.
As part of Swift for TensorFlow we have been working towards designing a set of protocols that more closely resemble mathematical concepts and can, for example, be used for conveniently implementing numerical optimizers. In trying to integrate our changes with the standard library we bumped into an issue related to Numeric. We have already designed a few protocols (e.g., VectorProtocol and PointwiseMultiplicative) for which we support automatic conformance derivation for aggregate types (e.g., structs containing tensors). We want to also support Numeric derivations for such aggregate structures and the current issue is that the Comparable constraint on Magnitude is causing some issues as it’s not straightforward what the semantics should be.
Ted Kremenek pointed out post by Argyrios Kyrtzidis about bringing formatting technology to SourceKit-LSP.
Formatting is integral to the experience of editing source code which why it is included in the LSP specification. This functionality, however, is currently missing from SourceKit-LSP. We want to provide users a great out-of-the-box experience of using SourceKit-LSP, across all editors and platforms, and first-class support for formatting is a critical piece of the experience.
For SourceKit-LSP we’d like to have formatting functionality that is:
- Fast and capable of real-time, “as you type”, performance
- Be robust and work even in the presence of invalid code
- Work in contexts that may only provide a string of Swift source code for context such as snippets in code-review
An excellent pitch by Owen Voorhees explaining another attempt in passing arrays as variadic arguments.
This proposal introduces a new expression,
#variadic
, which may appear in the argument list of a function or subscript call.#variadic
allows the user to pass anArray
’s elements in lieu of variadic arguments. This enables cleaner API interfaces and allows for the manual forwarding of variadic arguments.
Richard L Zarth III pitched an idea to allow for compile-time checked intervals for parameters expecting literal values.
Certainly methods are written to primarily accept literal values. However, when using types such as Int or Double there is no way to check at compile time that the supplied arguments are valid for a given interval/range. We must rely on run time checks that could cause for adverse side effects which may be difficult to handle.
Tom Doron informed about the SSWG-0007: Statsd
Client review.
After the discussion thread, we are proposing this as a final revision of this proposal and enter the proposal review phase which will run until the 29th July 2019.
The feedback model will be very similar to the one known from Swift Evolution. The community is asked to provide feedback in the way outlined below and after the review period finishes, the SSWG will – based on the community feedback – decide whether to promote the proposal to the [Sandbox}(https://github.com/swift-server/sswg/blob/master/process/incubation.md#process-diagram) maturity level or not.
Finally
Sometimes variable names can be quite long.