source link: https://swiftweeklybrief.com/issue-137/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Issue #137 27 Jun 2019
Written by: Bas Broek
It has at this point already been more than two and a half weeks since WWDC. While many are looking into the new tech announced there, as well as playing with the beta software, this is what has been going on in the Swift.org open source projects over the last two weeks.
Interested in sponsoring Swift Weekly Brief? Learn more here.
News and community
The second Server Side Swift Conference will be held on October 30th and November 1st, 2019, in Copenhagen, Denmark.
Commits and pull requests
A pull request was merged that
makes Dictionaries to not be rewritten into a call expression after type
checking. The new way is to keep the
LiteralExpr around and just stash a
reference to the right initializer.
Owen Voorhees opened a pull request fully qualifies names for types with the same name in either different modules, or different scopes. The diagnostic would be really confusing, and this change improves that.
Proposals in review
Doug Gregor has provided the following list of differences from the previous revision:
- The name of the feature has been changed from “property delegates” to “property wrappers” to better communicate how they work and avoid the existing uses of the term “delegate” in the Apple developer community
- When a property wrapper type has a no-parameter
init(), properties that use that wrapper type will be implicitly initialized via
- Support for property wrapper composition has been added, using a “nesting” model.
- A property with a wrapper can no longer have an explicit get or set declared, to match with the behavior of existing, similar features (
- A property with a wrapper does not need to be
- Reduced the visibility of the synthesized storage property to
- When a wrapper type provides
wrapperValue, the (computed)
$variable is internal (at most) and the backing storage variable gets the prefix
- Removed the restriction banning property wrappers from having names that match the regular expression
Equatablesynthesis are now based on the backing storage properties, which is a simpler model that gives more control to the authors of property wrapper types.
- Improved type inference for property wrapper types and clarified that the type of the wrappedValue property is used as part of this inference. See the “Type inference” section.
- Renamed the value property to
wrappedValueto avoid conflicts.
- Initial values and explicitly-specified initializer arguments can both be used together; see the
This amendment is to add a new method,
inverse(), to the
I was thinking about this a little bit and I actually think that there are two additional motivating actions here we are not considering:
We could use this to break the dependency of Swift based tools (e.x. swift-syntax) that Swift’s CMake builds on building the standard library.
CMake for free will let us integrate Swift code into swiftc itself trivially.
You can read the full overview here.
I’ve been slowly working on test discovery for Linux and I think the implementation is in a reasonable state now. I’ve tested it on some OSS Swift packages but it would be great if others can try it out and report any issues they run into. It can be enabled by passing the
--enable-test-discoveryflag to the swift test invocation.
Docker: Mishal joined to discuss publishing nightlies to Docker Hub. Happy to scope out doing this - it would involve some infra work from Apple but in principle happy to do this. We would prioritise Swift 5.1 convergence nightlies, add
masterafterwards. Would prioritise having the latest build available, historical builds can come later. Just full images, not slim.
Ubuntu 14.04 update: there are still users although usage is believed to be low. Mishal will check the stats. When we switch it off, we’ll start with
Naming collisions: Johannes explained the current status, post discussions around WWDC. There are a number of separate but related problems.
There are a number of projects implemented their own HTTP client libraries. This shows that there is a need for generic, multi-purpose, non-blocking, asynchronous HTTP client library built on top of SwiftNIO. The Swift Server Working Group aims to provide a number of packages that could be shared between different projects, and I think the proposed HTTP client library would be a good fit for those projects and other use-cases.
Having one, community-driven project that can be shared between different projects will hopefully solve the need to implement this functionality in every project from scratch.
Pavel Yaskevich opened a discussion to document feature/syntax use and error/warning scenarios for proposals.
Since we already have ABI, API resilience and Source Compatibility sections in the proposal template I think it might make sense to expand on that and make sure that proposal is considering not only correct syntax/use, but also accounts for (even if basic) scenarios when new feature/syntax is used incorrectly or in an (temporary) unsupported way.
I think it would make sense for proposals to state explicitly, in a separate section, what is supported and what is not (listing possibilities for future improvements), what is the possible initial set of diagnostic messages and some basic error/warning scenarios as well as what are the ways current feature might interact with other features already implemented in the language.
New attributes/keywords could be a good example - it would be very helpful to list contexts where new attribute/keyword could be used and what error message should be used for the rest. What are the special cases and areas of the future improvement e.g. currently could only be used on functions but later support could be expanded to properties and subscripts. How does new attribute/keyword interact with existing ones e.g.
I think having documentation like that in the proposal would make implementation as well as code review much easier, and would be generally helpful for posterity.
Swift UI introduces an
Identifiableprotocol as well as the related
IdentifierValuePairstypes and the
I believe that
Identifiableis a “currency” protocol with relevance to an extremely broad range of Swift code and should therefore be moved into the standard library along with the related types and method. These will be useful to any generic code that works with values that represent a snapshot of the state of an entity.
I’ve been working on getting nightlies of the Android SDK - the Swift standard library, libdispatch (and swift SDK overlay), as well as libxml2 and curl. Foundation is something which will take a bit more work, but is easily added. These are not exactly perfect, but should get you fairly up-to-date builds of the Swift standard library and libdispatch for the moment.
All of these builds are being done on Windows, but the generated artifacts are consumable on other targets as well (i.e. you can use this with an up-to-date toolchain on Windows, Linux, or Darwin). They currently target Android API level 21.