Discussion about removing `extra_traits` in 1.0

It has been proposed to remove the Eq, Hash, and Debug implementations as part of 1.0 https://github.com/rust-lang/libc/issues/3248. The reason for this is that for anything with padding or unions, it is not easy to ensure these are sound. An example is at https://github.com/rust-lang/libc/issues/2816.

I think the problem with this isn't always that they are unsound, but that their usage leads to unsoundness. For example, https://github.com/rust-lang/libc/issues/2700: they definitely shouldn't have relied on sigemptyset to fully initialize the struct, but there isn't anything that looks incorrect at first glance.

At this time, a very rough search shows about 850 Cargo.toml files that make use of this feature, compared to ~50k without it (https://github.com/search?q=lang%3Atoml+%2F%5Elibc%5Cs%2B%3D.*%22extra_traits%22%2F&type=code vs https://github.com/search?q=lang%3Atoml+%2F%5Elibc%5Cs%2B%3D%2F&type=code). This suggests there isn't a whole lot of ecosystem use that will experience breakage, but it also isn't negligible.

It seems Nix may be influenced by this more directly https://github.com/nix-rust/nix/issues/2468.

Personally I think we could leave a Debug implementation but just make non-primitive types nonexhaustive (e.g. sigset_t { .. }). This would at least allow #[derive(Debug)] on anything that wraps these types, and just make it always available rather than behind a feature.

There is a proposed PR up: https://github.com/rust-lang/libc/pull/3692

Start by reading the proposed PR and the linked discussions about extra_traits, especially issues 3248, 2816, 2700, and 2468. Compare the alternatives for Eq, Hash, and Debug implementations and determine whether the project has reached a decision; done means an agreed 1.0-compatible approach is implemented and its ecosystem impact is addressed.