PhantomData Debug Derive Macro

[Walter]

Thanks for the quick reply! And for including an example that would solve my problem! I really appreciate the effort.

@steffahn

Usually, when Debug-printing something, it is assumed that the type of the thing being printed is known, so the output only needs to be concerned with representing the value.

While this has been true until recently, the addition of the generic_const_exprs feature (still unstable - but available in nightly) has made this assumption false. Types can now have much more complicated values that are not obvious when looking at the source code alone. It's useful to have a way of verifying that the type you're constructing has the values you expect. For example consider this abstraction for creating a type that wraps arrays of even and odd length. I would like to verify that the length of that array and the type corresponds to my understanding of Even and Odd parity. Currently the fact that it prints out phantom: PhantomData does me no good:

[src/main.rs:11] [()].create() = ParityWrapper {
    inner: [
        (),
    ],
    phantom: PhantomData,
}
[src/main.rs:12] [0, 1].create() = ParityWrapper {
    inner: [
        0,
        1,
    ],
    phantom: PhantomData,
}

@steffahn

If you want to print the type of something, you can use compile-time tools such as IDEs

Not everyone wants to use these tools. Providing the users of rust with more options is better in my mind. I'm also sure there are situations where the runtime value and type are both not obvious, so a compile-time tools would fall short here.

@steffahn

Adding the type to the Debug output for PhantomData can have disadvantages: When types are long and complicated, then this addition could potentially significantly clutter the Debug output for your values.

I 100% sympathise with this idea - which is why I included it as an argument for not having types print for the general case. I do think PhantomData is a special case though - it only has one value. Most of the time I believe it's quite simple, and if it's not, you'd probably REALLY appreciate the debug output having that complex information along with it. Currently, just printing PhantomData is telling the user nothing really. IMO just printing PhantomData clutters the screen because it provides nothing the user doesn't know.

@steffahn

If you need a type-printing PhantomData anyway, you can also always build your own

It's not a case of need but rather a case of nice to have. I think it's a good idea to lower the barrier to entry for folk experimenting with type-level programming as much as possible. Rolling your own version is not something someone who's new to things and learning the landscape is going to do. The Debug trait coupled with the dbg! macro is a nice combination for learning and debugging.