Change Debug to use string representation

[cortopy]

Hi! I've been using xid for a few months and it works great, thanks for this!

However, I find myself struggling now that I've started debugging my program more often. Even though Id implements debug, it prints the raw bytes, which is not human-friendly at all when debugging and creates a lot of noise.

This PR just adds a manual implementation so that it prints the string

[kazk]

Hi! Thanks for the PR.

fmt::Debug is for showing the internals, and changing it to a string representation will make that impossible. Display is for a human-friendly output. I didn't realize Id didn't have impl Display 🤦‍♂️, so I added it in #5 and released v1.0.1.

[cortopy]

Debug as it is would be helpful for developing this crate itself, but a type like Id will most likely be part of a struct (e.g.: a User, a Purchase, etc.) which when debugging will be impossible to know which one it is by looking at the logs.

From the point of view of the consumer of this library, a stringified representation seems to make more sense. Indeed, libraries like uuid is what they do for both Display and Debug

[kazk]

a type like Id will most likely be part of a struct (e.g.: a User, a Purchase, etc.) which when debugging will be impossible to know which one it is by looking at the logs.

This crate doesn't have serde feature yet because I haven't needed it. It can be convenient to have deserialization to fail when an invalid id is found, but storing it as a string has been enough for my use cases. If you want it, I'll accept a PR.

The structs can implement custom Debug, too.

UUID's string representation is lower-hexed bytes, so it doesn't sacrifice anything.

That said, I agree it'll be convenient for the consumers. And I actually don't think keeping the current Debug will be that useful anyway.

[kazk]

Id("9m4e2mr0ui3e8a215n4g") looks like a newtype for string. How about this?

impl fmt::Debug for Id {
    #[inline]
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "xid:{}", self)
    }
}

println!("{:?}", id); // xid:9m4e2mr0ui3e8a215n4g

You'll need to rebase this to get Display.

[cortopy]

Id("9m4e2mr0ui3e8a215n4g") looks like a newtype for string. How about this?

impl fmt::Debug for Id {
    #[inline]
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "xid:{}", self)
    }
}

println!("{:?}", id); // xid:9m4e2mr0ui3e8a215n4g

You'll need to rebase this to get Display.

My first reaction was to think "is this Rust idiomatic?". In my experience all the tuple structs I've seen with Debug implemented use the format Name(value). To me this makes it apparent what it is, and what value it has.

Having something like xid:{} would suggest that if you do id.to_string() that's also what you get since the Debug printed value looks like a string after all?

[kazk]

My first reaction was to think "is this Rust idiomatic?"

I think idiomatic Rust is deriving Debug or custom Debug with similar output, and showing the internals. In this case, we decided not to for consumer's convenience, so we should optimize for that.

In my experience all the tuple structs I've seen with Debug implemented use the format Name(value). To me this makes it apparent what it is, and what value it has.

That's the problem I mentioned above. Id("9m4e2mr0ui3e8a215n4g") is what you get for

#[derive(Debug)]
struct Id(String);

which is misleading.

Having something like xid:{} would suggest that if you do id.to_string() that's also what you get since the Debug printed value looks like a string after all?

I don't think so? I'm fine without the prefix (just Display) if that bothers you.

[cortopy]

a type like Id will most likely be part of a struct (e.g.: a User, a Purchase, etc.) which when debugging will be impossible to know which one it is by looking at the logs.

This crate doesn't have serde feature yet because I haven't needed it. It can be convenient to have deserialization to fail when an invalid id is found, but storing it as a string has been enough for my use cases. If you want it, I'll accept a PR.

The structs can implement custom Debug, too.

UUID's string representation is lower-hexed bytes, so it doesn't sacrifice anything.

That said, I agree it'll be convenient for the consumers. And I actually don't think keeping the current Debug will be that useful anyway.

Thanks so much for reconsidering this! Yes, serde has human friendly formatting (which normally is associated with Debug) as a very explicit way of dealing with this.

Having said that I'm not using Serde but minicbor. I'm storing xid as bytes because minicbor encodes full structs to bytes in my program. Hence, my difficulties in debugging with debug, as the whole bytes array is shown

[kazk]

I decided to merge this as is, before I forget. It's honestly not a big deal. I don't really need this either, and it works for you.

We can change this later if someone thinks it's misleading.

[cortopy]

@kazk I'm so sorry I didn't reply earlier, this somehow fell through. Thank you for approving this!