Represent arguments better

[elidupree]

Currently, we always use Debug, which isn't great for the generated regression tests because it's not an accurate representation of how to construct the value in code – e.g. a boxed 5 renders as 5, but we want it to render as Box::new(5).

The high-tech solution would be to implement my own trait, call it ConstructionCode, that generates the appropriate string, make it public, and provide a derive macro for it. This could even be a separate library crate, since I imagine it would be useful for things other than this library. A more short-term, future-compatible solution would be to implement such a trait privately, and fall back to Debug when it's not provided.

[elidupree]

I'm thinking maybe the trait could be called BestEffortConstructionCode, borrowing the term "best-effort" from the documentation for std::any::type_name

[elidupree]

Also, at least in Nightly, we can use specialization to make the Debug/whatever impl available even in generic code; right now this is especially troublesome in trait tests, which only have supertraits available, so if Debug isn't a supertrait, it always says <no Debug impl> even if the concrete type implemented Debug. (And I can't just have the trait implementor pass a closure into the trait function because of object-safety difficulties... well, maybe if the closure was a boxed trait object and didn't return the argument representations, but just wrote them into the local variable...)

[elidupree]

A pragmatic alternative is to use serde_json.

• Widely supported and I don't have to maintain custom code
• Because JSON is human-readable, this is just as resilient to code re-factoring as generating constructor code
• Because JSON is human-readable, the resulting regression tests are only moderately less readable than constructor code
• The lossy aspects of serde_json (None vs Some(None), floating-point rounding) will almost never cause problems