A typealias could hide the complexity, like typealias AnyBacktrace = any<A: Address> Backtrace<A>. But I see your point that being generic over integer sizes may end up just being unnecessary complication in practice. Regardless though, if different platforms end up needing different types in the backtrace, I think generics and generalized existentials would be the way to go. Maybe packaging multiple types into a single generic parameter conforming to a BacktracePlatform protocol if there would otherwise be too many generic parameters.
1 Like
Reading back through this, I realised that maybe you thought that this would only symbolicate with Core Symbolication, and not e.g. on Linux. To clarify, it already supports symbolication on Linux, including the ability to find symbols in all the usual places (including those compressed into your binaries, or installed in the relevant places in the filesystem). It doesn't, as you correctly identify, support debuginfod, at least not today; there's no fundamental reason we couldn't extend it to do so in future, though at present performing network accesses from the existing code is tricky for build process/dependency related reasons.
It also captures sufficient information that you could use an un-symbolicated backtrace to symbolicate later on; there's no API or tooling provided for that yet, and none proposed in this SE, but it's something I'd like to look at in future.
5 Likes
+1 to this. Usage of generalized existentials would also prevent anyone from using this API in Embedded Swift, if that configuration is ever supported.
1 Like
Two brief pieces of API naming feedback: The properties noCache and inlined (of different types), being Bools, should probably be more like hasSharedCache and wasInlined. In the case of the first, it's a bit unusual to name the property in the negative, since a false value would have to be read as a double negative.
6 Likes
Hi all: I'm extending the review period to run through February 20th to allow Alastair to incorporate collected minor feedback from the review.
1 Like
Quick question: This proposal adds a Runtime module. Do we think this would also be an appropriate module name for the demangle APIs that were proposed in SE-0262?
One of the reasons that proposal was returned for revision was that we felt its APIs were too niche for the standard library and ought to be in a more specialized module. Now that we're adding such a module, we should make sure it has a name that would be suitable for the demangle functions as well.
(To be clear, I'm not suggesting that we increase the scope of this proposal to include demangling—just that we should think about whether we're doing something that would work for it.)
15 Likes
The Runtime module sounds like a fine place for a demangle API, for sure. (And I'd probably have used that in the backtracing code if it had existed 
)
7 Likes
Thanks all for participating in this revision review! The proposal has been accepted with modifications.
5 Likes