derive Debug on structures?

[dimbleby]

It's my understanding that implementing Debug on structures is generally a Good Thing. Types provided by this library do not implement Debug. Is this by policy, or by omission?

(I tried some quick messing around with the s! macro and failed to persuade it to #[derive(Debug)]. But I suppose that this ought to be possible, if it is indeed desirable).

[kamalmarhubi]

In #159 (comment), @alexcrichton said

Currently, however, the libc crate is intended to be as thin a wrapper as possible around the system libc, for example it only provides the guarantee that structs are Copy (which also forces a Clone impl).

At this time we're not looking for higher level abstractions in libc (e.g. any other form of "Rust code" like Eq or Hash). That's in general left to higher level libraries.

I expect this will apply to Debug as well. The aim, as I understand it, is that libc should be as close to nothing-but-declarations as possible.

[dimbleby]

Interesting.

A couple of data points:

• winapi does #[derive(Debug)] wherever it can
• So does libcore (as of libcore: add Debug implementations to most missing types rust#32054, and some of the discussion there likely applies here).

[alexcrichton]

Oh this was actually something I forgot to implement. The intention of the original RFC was:

As a technical detail, all struct types exposed in libc will be guaranteed to implement the Copy and Clone traits. There will be an optional feature of the library to implement Debug for all structs, but it will be turned off by default.

That optional feature just hasn't been implemented yet. Shouldn't be too hard to do though!

[kamalmarhubi]

Giving this a shot. Two issues so far:

• can't derive Debug on structs that have large arrays embedded, since it's only implemented up to 32-element arrays, so there will be some messiness instead of hiding it all away in the s! macro
• I think there's a bug with derive(Debug) when fields have a #[cfg(...)] attribute on them. The expanded impl is referencing the fields that are excluded by the attribute, leading to either matching a non-existent field, or binding the same field twice. I can't repro in a top-level struct outside of libc, still taking a look.

[Susurrus]

I just ran into this again today with both Eq and Debug. For developing nix we have a large number of structs that are just newtype wrappers around libc types and we'd like to derive some of these traits on these structs. Many of these structs vary per-platform, and we support a lot of platforms, so it's tough to manually implement some of these.

So in the 1.5 years since this issue was opened a lot has changed. With compile times actively seeing work over every release cycle and also the Rust API Guidelines specifying that many derives should be added for structs, I'd like to revisit this. I'll write up an RFC this week and we'll see where we get!

[Susurrus]

I've now filed a PR for this RFC: rust-lang/rfcs#2235

[gnzlbg]

The RFC was partially implemented, closing this in favor of the tracking issue: rust-lang/rust#57715