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 Demangle Function, and so we are returning the proposal for revision.
- A lot of the discussion explored the details of the unsafe buffer-based API, which was offered as a means of accessing the demangler in a limited runtime context, such as a crashed process or a signal handler. However, the current demangler implementation is not suitable for such applications, because even if it were given a preallocated output buffer for the returned string, it still freely allocates in the course of parsing the mangling and forming the parse tree for it. Presenting an API that might seem safe for use in contexts that can't allocate would be misleading at this point, so the core team recommends dropping the unsafe variants from the proposal, leaving only the
(String) -> String?variant.
- Jordan Rose raised the questions of what specific use cases this API is intended for, and what variation of demangling output it uses. The core team believes that the use cases for this API are clear—the aforementioned cases of logging for diagnostic purposes. However, the proposal should consider what form of demangling output the API generates. The core team recommends supporting at least the "simplified" form (used by lldb, Instruments, and similar tools by default, or
swift-demangle -simplified) and the full form (used by
swift-demangle's default mode).
- Brent Royal-Gordon raised the concern of polluting the global namespace with a relatively niche, low-level function. Independent of this proposal, the Core Team would be interested in starting discussion of a "Runtime" module, akin to
<objc/runtime.h>in Objective-C or
libc++abi, that provides access to low-level functionality and data structures in the Swift runtime that can be used for reflection and diagnostic purposes but should not be part of the standard library. The Core Team thinks that the proposed
demanglefunction makes sense as a standalone, top-level function. However, it would be a natural candidate for such a Runtime module if it existed.
Thank you to everyone who participated in the review!