By supporting extensions, the macro can be applied to existing CustomDebugStringConvertible conformances where the debugDescription meets the requirements of the macro. Some of these existing debugDescription properties will be defined in extensions. We don't want developers to have to duplicate their debugDescription.
Correct. The debugger can print all of its properties, but this is to provide a more succinct string representation for developers to digest, or use to quickly identify one value from others.
cc @James_Dempsey@tommyming – this is the reason examples show CustomDebugStringConvertible, because codebases will contain be many existing conformances. One of the design motivations is for the macro to be able to reuse many existing debugDescription definitions.
According to the motivation, I am thinking about the following implementations:
protocol AnotherDebugStringConvertible {
var debugDescription: String { get }
}
@DebugDescription
struct Order: AnotherDebugStringConvertible {
let orderName: String
let orderId: Int
var debugDescription: String {
"\(orderName) \(orderId)"
}
}
Another one:
@DebugDescription
struct Order: Equatable {
let orderName: String
let orderId: Int
var debugDescription: String {
"\(orderName) \(orderId)"
}
}
May I know if both implementations are the correct usage of the macro?
Cool! Would say this macro definitely helps a lot on debugging.
Personal comment:
it provides more flexibility than debugPrint or Error.localizedDescription from the standard library. And it provides an extra option apart from 3rd party debug loggers.
and agree on this, having the macro name on the error helps on clarity while debugging.