re-export traits together with the derive

[JelteF]

This seems quite nice for traits that are not in the prelude. Often if you're deriving things you also want to use them.

[JelteF]

Sadly this is not easy to do without opening ourselves up to unfixable breakage if Rust decides to add some derives for these traits too. This showed up already for the Debug trait. See #273 for details.

[JelteF]

So removing this from the 1.0.0 milestone.

[JelteF]

Blocked by trait aliases rust-lang/rust#41517

[awused]

This causes a lot of breakages in code that has compiled, unchanged, for years, and there doesn't seem to be any real benefit to it.

Honestly it seemed like such a serious mistake that wasn't even mentioned in the release notes for 1.0.0 that I was halfway done filling out a bug report. I'm surprised it was an intentional change.

edit: I did eventually find it buried under "breaking changes," must've just missed it the first time I read them.

[tyranron]

@awused this also is explicitly mentioned and described in the README of the crate both on GitHub and crates.io/docs.rs:

• https://docs.rs/derive_more/1.0.0/derive_more/#re-exports
• https://github.com/JelteF/derive_more/tree/v1.0.0?tab=readme-ov-file#re-exports

We were quite aware of the unpleasant consequences of this breakage, as had the experience of large code bases migration during 1.0.0-beta.x cycles. That's why, as described in the README, we still left the option to import macros only:

use derive_more::derive::Display; // imports macro only

If you don't have enough time/resources for the full migration, this can ease it just by doing the following replacement in the project:

s/use derive_more::/use derive_more::derive::/

[awused]

Sure, it's mentioned in the readme, but it's not like I re-read every readme on every update. I ran into what I thought was a clear mistake and was about to file a bug, because it didn't seem at all reasonable that one crate would be making decisions on what parts of another crate I wanted to import. Even if that second "crate" is std, it's a bizarre overreach; there's certainly no other crate I can think of that does anything like this, not that many crates would have the opportunity. It leaves a bad taste in my mouth that any library would make that decision for me.

As for the migration, it's not actually about the amount of work required - contrary to the premise of this feature request, it seems quite common to derive a trait without using it, so the actual positive impact of this change is rather negligible. In several of my projects this change had no impact besides breaking compilation in files where I had both a manual definition of a std trait alongside a derive_more derivation.