Feature Request: CustomDumpReflectable without a Mirror

[Smiley Rob]

I really appreciate the pretty printing of customDump(). However I'm having some challenges with using Mirror in some cases and would like to suggest a new API that prints like a displayStyle: .struct but allows me to explicitly override the typeName.

(Please ignore the protocol naming. I'll trust you guys to come up with something suitable)

extension MyType: CustomDumpValueRespresentable {
  var customDumpValue: CustomDumpValue {
    .init(
      typeName: if isButton ? "Button" : "MyType",
      children: [
        "child": child,
        ...
      ]
  }
}

Thanks.

[Stephen Celis]

Hey @rjchatfield! I'm going to convert this to a discussion, since we try to keep the issues area focussed on bugs with the library.

I believe there are several existing ways of achieving what you want here. The two that stick out the most:

1. One would be to use the CustomDumpRepresentable protocol instead. You could use it to swap in a private struct for dumping:

   extension MyType: CustomDumpRepresentable {
     var customDumpValue: Any {
       struct Button {
         var child: ...
       }
       struct MyType {
         var child: ...
       }
       return self.isButton
         ? Button(child: self.child, ...)
         : MyType(child: self.child, ...)
     }
   }

   It's admittedly more verbose, though it avoids string interpolation, etc.

2. The CustomDumpStringConvertible protocol could be used to return the string dump, instead:

   extension MyType: CustomDumpStringRepresentable {
     var customDumpDescription: String {
       let typeName = self.isButton ? "Button" : "MyType"
       var children = ""
       customDump((child: self.child, ..., to: &children)
       return "\(typeName)(children)"
     }
   }

   This may feel a bit "magical", but should be totally safe to do, and this one could even be abstracted away in your own type/protocol.

If you come up with a reasonable, repeatable way of handling the problem, please do share in the discussion! And if this is something that comes up enough, we can share the solution or include the solution in the library proper. For some reason, we haven't encountered this issue ourselves in the libraries and apps we use CustomDump in.

We already consider the three existing protocols to be a lot, so ideally we'd want to avoid introducing a fourth one to the library if we can.