Another two weeks have passed, so here’s another “Weekly” Brief. There’s lots of energy within the community at the moment, it seems — as there’s a lot going on.
LINE is the leading mobile messaging platform in Japan and boasts one of the largest Swift codebases in Asia. In addition to supporting Swift versions from day 1, we strongly value semantics, protocols, and strongly typed systems. Many of our members are also active in the OSS community and support both local and global meetups and peer labs. Come join us and see what Swift can do in the real world.
- SR-13119 [Compiler] Confusing diagnostic when checking conformance for IUO of generic parameter
- SR-13092 [Parser]
operator $produces two contradictory error messages
News and community
Tom Doron announced Swift Service Lifecycle, a new open source project for the Swift server ecosystem. It is a Swift package designed to help server applications, also known as services, manage their startup and shutdown sequences.
Commits and pull requests
Proposals in review
Currently, variadic parameters in Swift are subject to two main restrictions:
- Only one variadic parameter is allowed per parameter list
- If present, the parameter which follows a variadic parameter must be labeled
This proposal seeks to remove the first restriction while leaving the second in place, allowing a function, subscript, or initializer to have multiple variadic parameters so long as every parameter which follows a variadic one has a label.
In SE-0274, the core team accepted a proposal to change the behavior of
#file. This proposal modifies that plan to transition into new behavior more gradually, treating it as a source break requiring a new language version mode to fully adopt.
It has been a while since SE-0177 was sent back for revision (three years?) and it might be worth it to start a new thread here about what to do with SE-0177.
At the moment I have one pull request for the Swift Evolution repository and another pull request adding
clampedas an extension on
Comparableto the standard library.
I would love to start this discussion with everyone about what to do next until SE-0177 is complete.
SE-0279 “Multiple Trailing Closures” threaded the needle between getting the syntax we wanted for multiple trailing closures without breaking source compatibility. One aspect of that compromise was to extend (rather than replace) the existing rule for matching a trailing closure to a parameter by scanning backward from the end of the parameter list.
I propose that we replace the backward scan used by the trailing closure matching rules with a forward scan, which is simpler and works better for APIs that support trailing closures (whether single or multiple) as well as default arguments. This is a source-breaking change that affects a small amount of code: I propose that we take the first (smallest) part of this source break immediately, to be finished by a slightly larger source break in Swift 6.
To get a feel for the new behavior, it really helps to write some code against it. I implemented this proposal in the Swift compiler, and have built both a Linux and a macOS toolchain that support it. Using this toolchain, you can experiment with the new behavior. Please try it out!
Introduce a new attribute to warn when an overridden function does not call the
supermethod in its body.
It is quite common to override a method in order to add additional functionality to it, rather than to completely replace it.
At present, there is no way to communicate this need other than adding it to the documentation and even experienced developers sometimes overlook this small detail and later run into various issues at runtime.
In Objective-C, one can annotate a superclass method with the
objc_requires_superattribute and the compiler emits a warning when an overridden method is missing a call to the
supermethod in its body.
However, there is no such attribute in Swift.
availableattribute documents characteristics of a declaration’s lifecycle. The attribute specifies when a declaration became available on a given platform, and if it’s been deprecated, obsoleted, or renamed. We feel there’s room to further nuance
available. This proposal expands
discouraged, making declarations harder to accidentally use.
I don’t often come across a data modeling problem where circular referencing appears to be a good solution. In general I find that arguments that attempt to justify circular references appear contrived (
Apartment <-> Person), and because of that lacking any true real world applicability. That said, circular referencing isn’t always an attempt at a data modeling solution, more often than not I find it’s an attempt at an encapsulation solution.
Often when defining complex models code files can become large and in an effort to make the repository more digestible functionality and properties are encapsulated into smaller bite-sized classes. The problem arises when some of those bite-sized classes require access to data within the original scope.
Swift’s Property Wrappers allow for wrappers without arguments to defer specifying the wrappedValue until the initialization of the containing type. This proposal adds this feature to Property Wrappers that have multiple arguments by extending the current initializer synthesization.
I’m proposing the introduction of an inverted scope for the
guard letpattern. The problem occurs most commonly when propagating errors to completion handlers.