[Second Review] SE-0440: DebugDescription macro

Evolution Proposal Reviews
1

Hello, Swift community!

The first review of SE-0440: DebugDescription Macro ran through July 16th, 2024; the LSG decided to return the proposal for revision to address three issues:

  1. The macro as implemented did not work with generic types or protocols; this was not documented in the proposal, nor was a diagnostic generated for these cases.
  2. The LSG thought it best if ${ did not require escaping such that the Swift property and the lldb summary always print exactly the same thing.
  3. _debugDescription should not be an underscored property. It incorrectly suggests that this is an implementation detail, rather than a user-facing feature for lldb interoperability. We suggested the name lldbDescription instead.

The author has incorporated this feedback into the implementation and proposal text, and we will have a focused re-review for these changes run from now until July 30th.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or DM. When contacting the review manager directly, please put "SE-0440" in the subject line.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?

Is the problem being addressed significant enough to warrant a change to Swift?

Does this proposal fit well with the feel and direction of Swift?

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available here .

Thank you,

Steve Canon
Review Manager

6 Likes
2

Can the _lldb_summary properties have private access? Otherwise, a subclass and its superclass can't have different LLDB Type Summaries.

class A {
  static let _lldb_summary = (1 as UInt8, 2 as UInt8)
}

class B: A {
  static let _lldb_summary = (3 as UInt8, 4 as UInt8, 5 as UInt8)
  // error: cannot override stored property…
}

Are there size limits for compile-time constants, such as _lldb_summary tuples?

Would a tuple type alias help (or hinder) type checking?

extension C {
  private typealias _Tuple10<T> = (T, T, T, T, T, T, T, T, T, T)
  private static let _lldb_summary: _Tuple10<UInt8> = (1, 2, 3, 4, 5, 6, 7, 8, 9, 0)
}
3

After a quick reading,

A Few Questions:

  1. I am expecting debugDescription can ONLY be identified by the macro when protocol CustomDebugStringConvertible or CustomStringConvertible is conformed by the property. Therefore, using either these 2 protocols is a requirement of the macro?

  2. Just a suggestion, is it better to add example of:
  • Using ONLY lldbDescription
  • Using BOTH debugDescription and lldbDescription, according to proposal.
    for clearer explanation, since both properties have different purpose?

Comments:

I think the refined proposal explains clearer than the 1st edition. (Yeah I totally missed the _debugDescription part, which causes me asking some dumb questions on the last review. My bad).

About the "future direction" part, I am skeptical about the macro should be implemented to Generics also.
Based on my usage of other debug loggers/implementations, I rarely assign them to Generics. When I want to use the debug related stuff, I would directly put them to the specific property/type, let the compiler tell me what's inside.
It would be great to see some examples!

Feel free to correct me if there's anything wrong, thanks.

4

I see the utility of the feature, but I am unconvinced it rises to the level required for inclusion in the standard library. A sidecar package might be a better home for it.

5

@Dave_Lee can correct me if I get this wrong, but I believe that the macro does not interact with these protocols at all, other than (optionally) using the same property name as an implementation hook. There is no requirement that a type that uses the macro conform to either of these protocols.

1 Like
6

Thanks for the reply. Can correct me in case I missed something.

Just tested on Xcode 16 Beta 3, seems the macro does not require protocol conformance. And it loads the content inside debugDescription.

7

Yes confirmed, the macro can be used independently of CustomDebugStringConvertible. Whether one or both are used depends on the needs of the developer, or the data type. Existing types that have conformance can stay that way, new uses of the macro (where no existing conformance exists) can opt to use only the macro.

1 Like
8

This proposal has been accepted.

2 Likes