Issue #126 24 Jan 2019
Written by: Bas Broek
Last week we saw the introduction of a new Swift Community Podcast. The podcast is set up in a similar way (and inspired by) this very Newsletter, fostering the Swift Community, encouraging anyone to help out.
I think this is a really exciting project and am looking forward to seeing the Swift community bring it to life!
And without further ado, here is an update on the last two weeks in Swift open source.
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-9670 [Compiler] Driver should accept
-serialize-diagnostics-pathfor the interpret mode
- SR-9677 [Compiler] Using break with unresolved label inside loops produces misleading diagnostic
John, Garric and Chris introduce the Swift Community podcast, talking about its concept and their first impressions of Swift.
News and community
I think this has the potential to be great for data science.
Commits and pull requests
Thank you everyone for the very insightful feedback provided during this review. It provided some great insights into the Swift’s community uses and desires on Codable.
Regarding the proposal itself, the Core Team has decided to accept it, with the proposal amended to include the details of the encoding format chosen. The data encoding chosen is an important semantic invariant of the API that is potentially observable by users and important for binary compatibility. Future proposals like this one that discuss adopting
Codableshould include details — and when necessary — rationale on the encoding chosen. Further, it would be valuable if the current chosen encodings for Standard Library types were also documented so that users using the default encodings for those types can either rely upon those encodings or know when they need to customize their encoding logic for a specific task.
In addition, the Core Team decided to extend the proposal to include
ContiguousArray, which was similarly missing from the Standard Library. This felt like a case that required no additional review discussion.
Proposals in review
This proposal describes additions to the standard library that provide an interchange format for diffs as well as diffing/patching functionality for ordered collection types.
Representing, manufacturing, and applying transactions between states today requires writing a lot of error-prone code. This proposal is inspired by the convenience of the
diffutilssuite when interacting with text files, and the reluctance to solve similar problems in code with
Many state management patterns would benefit from improvements in this area, including undo/redo stacks, generational stores, and syncing differential content to/from a service.
One-off closures that traverse from a root type to a value are common in Swift. Consider the following
mapallows the following code to gather an array of emails from a source user array:
filtercan collect an array of admins:
These ad hoc closures are short and sweet but Swift already has a shorter and sweeter syntax that can describe this: key paths.
Recently, I wrote a coverage-guided Swift fuzzer similar to
libFuzzer, but I found that SwiftPM did not allow me to specify the build settings I needed, and I had to fork SwiftPM to make my project work.
Using a coverage-guided fuzzer requires the tested targets to be instrumented with LLVM’s SanitizerCoverage, which is kind of possible to do now with the option
-sanitize=fuzzerwhen using a development version of
swiftc. And it is possible to add that option to a package because SwiftPM supports custom build settings thanks to SE-0238, but only for targets that are declared in the root package, not for targets declared in a dependency.
Moreover, instrumenting a target makes its resulting binary unfit to be used for any other purpose than fuzzing, so I believe it would be best to isolate the products of a “fuzzing” build by using a separate build configuration than debug or release.
Working my way through the
swift-corelibs-foundationfor Windows, I think I have gotten to the point where I believe that the last items preventing Windows support for Foundation can now be enumerated:
- Porting the remaining interfaces in Process, Thread, FileManager, and Host
- Fixing the VWT handling for ForeignClassMetadata strategy
- Fixing protocol witness table emission to be exported from the standard library
- Identifying the desired behaviours for curl/libxml2 linkage
The first three are more technical, the implementation for the interfaces just need someone dedicated enough to work through the surface and with some time. The second would be something that is more involved, the third is just a bug.
[..] For those interested in the rest of the Windows port, especially those interested in helping getting Foundation running on Windows, do checkout the work in progress pull request. I would certainly love some help!
// Welcome to the world of software development.