Issue #139 25 Jul 2019
Written by: Bas Broek
It has been a while! The previous issue was beautifully crafted by Kristaps Grinbergs. Thanks again so much for that!
With all the heat (in Europe, at least…) I hope you’re keeping it cool.
Join us on 9th October for 4 amazing workshops, continuing on 10th - 11th October for 18 sessions with the greatest international speakers. Be part of something unforgettable: meet the experts, talk with fellow developers and discover new technologies, all in the charming Bologna, while eating some fine food.
More than a conference, in the Italian way.
- SR-11148 [Compiler] Separate
whileblocks generate error from legacy diagnostic
- SR-11159 [Compiler] Typechecker
crash on overloaded
News and community
Edd Wilder-James shared an update on expanding Tensorflow in the open, announcing a special interest group for Multi-Level Intermediate Representation (MLIR), an intermediate representation and compiler framework.
Commits and pull requests
Erik Eckstein merged a pull request
that makes Swift traps more user-friendly. By encoding the error message in the
DWARF line table, you’ll see the message in
.dSYM-symbolicated backtraces and
crash reports, without strings leaking in your binaries.
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.
Introduce a new standard library function,
demangle, that takes a mangled Swift symbol, like
$sSS7cStringSSSPys4Int8VG_tcfC, and output the human readable Swift symbol, like
Swift.String.init(cString: Swift.UnsafePointer<Swift.Int8>) -> Swift.String.
Currently in Swift, if a user is given an unreadable mangled symbol, they’re most likely to use the
swift-demangletool to get the demangled version. However, this is a little awkward when you want to demangle a symbol in-process in Swift. One could create a new
Processfrom Foundation and set it up to launch a new process within the process to use
swift-demangle, but the standard library can do better and easier.
In the event of a fatal error caused by Swift code, there is no direct way to get the error message and context from Swift without out-of-process log parsing. Fatal errors “fall through” to signal handlers at which point the crash context is lost. The goal of this proposal is to provide a native Swift cleanup callback for fatal errors without the complexity of signal handlers nor allowing attempted recovery. This context could be written to disk or logged in a custom format or aggregated for later analysis.
Some of you may remember SE-0220 my proposal that added the
count(where:)function to sequences. This proposal was ultimately accepted in time for Swift 5, but sadly had to be reverted because it was causing issues with the type checker.
The issue was that when you reference
count, in an expression like
myArray.count * 5, you could be referring to the count property, with type
Int, or the
count(where:)function, which has type
((Element) -> Bool) -> Int, which you can refer to in shorthand as
count. When Swift tries to resolve what version of the
*function to use, it has to run through a lot more potential implementations, which explode combinatorially as you increase the number of operators in the expression.
I’ve thought about this problem for a while and chatted with a few folks about the issue, and I think the simplest path forward to solve this is to require parameter names when referencing functions.
A lot of code written to support more than one platform contains
#if arch()conditions to handle differences between 32-bit or 64-bit platforms or little and big endian CPUs. This may turn into long statements like
#if arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le), enumerating every (currently) supported architecture which must be handled by that
#if ... #endifclause.
Prometheus is one of the most widely used libraries for metrics in the serverside world. SwiftPrometheus is a client side implementation in Swift, with the ability to use it both connected to & separately from swift-metrics.
With Prometheus being one of the most widely used metric reporting tools, it’s a buildstone that can not be left out in a serverside ecosystem. This package is created for everyone to use & build upon for their metric reporting.