That would allow us not to water down description
/debugDescription
; however, I wonder if the limitations of what the macro can understand will end up frustrating work.
For instance, Swift isn't great at handling bit fields, and types that need to manually implement them would be obvious candidates for custom-made lldb summaries -- trying to debug code that deals with such types is always painful.
For example, would it be at all possible to implement the summaries we made for String.Index
in this macro setup? They heavily rely on computed properties and integer expressions.
I expect having to manually construct a Python expression to emulate these would be far less frustrating than having to try to fit things into whatever ad-hoc, ill-designed, and undocumented subset of Swift the macro will end up supporting.
extension String {
/// A position of a character or code unit in a string.
@frozen
public struct Index: Sendable {
@usableFromInline
internal var _rawBits: UInt64
...
}
}
extension String.Index {
@_alwaysEmitIntoClient
internal var _encodingDescription: String {
switch (_rawBits & Self.__utf8Bit != 0, _rawBits & Self.__utf16Bit != 0) {
case (false, false): return "unknown"
case (true, false): return "utf8"
case (false, true): return "utf16"
case (true, true): return "any"
}
}
/// A textual representation of this instance.
@_alwaysEmitIntoClient
@inline(never)
public var _description: String {
// 23[utf8]+1
var d = "\(_encodedOffset)[\(_encodingDescription)]"
if transcodedOffset != 0 {
d += "+\(transcodedOffset)"
}
return d
}
}