SE-0440: DebugDescription macro

Thanks for the reply. Feel free to correct me if I am wrong.

I was first looking for something that is similar to Error.localizedDescription, when talking about default format.

But after reading the PR and proposal, seems it is a different case, sorry for confusion.

The macro requires developers to define their own debug description format for the macro, to my understanding.

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.

2 Likes

Thanks for the clarification.

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?

Thanks!

This issue is mostly fixed in Xcode 16 beta 3 (16A5202i).

The diagnostic has a file:line:column in the build log, and the property has an error message in the source editor.

For the sake of clarity, should you include the public macro's name in the error messages?

2 Likes

Yep, both of those examples are valid uses of the macro.

1 Like

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.

This proposal has been returned for revision.

1 Like