Issue #142 05 Sep 2019
Written by: Bas Broek
While I have the feeling I’ve had a busy two weeks, it seems like I haven’t been the only one…
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-11397 [Standard Library]
FixedWidthInteger.init?(_: radix:)fails for
- SR-11418 [Compiler / Standard Library] Add Graph Algorithm benchmarks to test
- SR-11419 [Compiler]
missing_witnesses_generalShould only be emitted in IDE mode
- SR-11420 [Compiler] Protocol Stubs Should Suggest Requirement Stubs for Renames As Well
- SR-11421 [Compiler] Checked Cast Diagnostics Should Be More Specific When Literals Are Involved
On the latest episode of Swift Unwrapped, Jesse and JP discussed Binary Dependencies in Swift Package Manager.
News and community
Swift 5.0.3 for Linux has been released.
Commits and pull requests
The core team supports having standardized functionality for turning a Swift symbol name into a human-readable string for logging, debugging, and crash reporting purposes. However, many important design points were raised in the review of SE-0262, and so we are returning the proposal for revision.
SE-0042 was formally accepted more than three years ago. However, since the proposal was accepted before having a working implementation was a requirement, and the change would be source breaking, and also require massive rewrites of the compiler; it is now clear that this proposal will never actually be implemented. It has been obvious for a long time.
Proposals in review
This proposal suggests a new initializer for
Stringthat provides access to a String’s uninitialized storage buffer.
Stringtoday is well-suited to interoperability with raw memory buffers when a contiguous buffer is already available, such as when dealing with
malloced C strings. However, there are quite a few situations where no such buffer is available, requiring a temporary one to be allocated and copied into. One example is bridging
String, which currently uses standard library internals to get good performance when using
CFStringGetBytes. Another, also from the standard library, is
Float, which currently create temporary stack buffers and do extra copying. We expect libraries like SwiftNIO will also find this useful for dealing with streaming data.
This pitch introduces
OffsetBound, which can represent a position in a collection specified as an offset from either the start or end of the collection (i.e. the collection’s “bounds”). This covers an expressivity gap in collection APIs by providing easy and safe means to fetch an index or element from such an offset as well as convenient slicing.
If you would like to try it out, you can just copy-paste from this gist, which includes the functionality as well as test cases and examples.
I wonder if there are plans to add a “does X conform to Y” request to the request evaluator system (or other ways to unify conformance lookup logic)?
I’m curious because there multiple ways to perform conformance lookup (and find associated type witnesses), some of which have caused bugs for the differentiable programming project, which needs
Differentiableconformance lookup and associated type witness lookup during Sema, SILGen, and SIL transforms.
In my experience, the static function
TypeChecker::conformsToProtocolhas been the most reliable way of obtaining a conformance (over
ModuleDecl::conformsToProtocol), but it is available only during Sema, not during SIL.
Lately, I’ve been thinking about how the diagnostics user experience for Swift could be improved in the long term. I thought it would be valuable to start a conversation around what kind of improvements people would like to see and what we can learn from other compilers, maybe resulting in some kind of rough roadmap if there’s enough interest.
A closure is said to escape a function when the closure is passed as an argument to the function, but is called after the function returns . When you declare a function that takes a closure as one of its parameters, you can write @escaping before the parameter’s type to indicate that the closure is allowed to escape.
Quote from the Swift documentation
This statement is not always true when considering optional closures passed as function parameters.
This proposal aims to uniform the behaviour of optional closures with the well-known behaviour of non-optional closures when passed as function parameters.