Issue #138 11 Jul 2019
Written by: Kristaps Grinbergs
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.
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.
- 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”
News and community
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
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
This proposal introduces an
Identifiableprotocol, 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
Identifiableand related types into the standard library
- 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
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
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.
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.
#variadicallows the user to pass an
Array’s elements in lieu of variadic arguments. This enables cleaner API interfaces and allows for the manual forwarding of variadic arguments.
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.
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.
Sometimes variable names can be quite long.