Re-export traits #273
Re-export traits #273
Conversation
This is blocked until [trait aliases are allowed][1]. Because right new we'd also export any derives from std with the same name. This showed up with the Debug derive. But if rust starts implementing more derives for their built in types in std, then the same issue would occur for other traits. [1]: rust-lang/rust#41517
|
I created this issue on the internals forum: https://internals.rust-lang.org/t/use-ing-only-a-trait-not-a-derive-with-the-same-name/19153 |
|
@JelteF could you specify an example where it causes trouble? I don't understand where the conflict appears exactly. |
|
@JelteF ok, investigated this a liitle bit more and understood the problem. Seems like this answer does the trick even if Will commit fix shortly. |
|
It also makes traits visible in docs, but I do prefer this. It's much more confusing to not see traits in docs while they're imported, actually. |
src/lib.rs
Outdated
| // XXX: Uncommenting this causes our own derive to not be visible anymore, because the derive | ||
| // from std takes precedence somehow. | ||
| // #[cfg(feature = "debug")] | ||
| // #[doc(hidden)] | ||
| // pub use core::fmt::Debug; |
There was a problem hiding this comment.
To be clear, this was the example that caused issues.
Yeah, that's a clever trick. Using that seems fine to me.
On one hand it's nice, on the other hand it clutters the derive_more docs quite a bit. Especially since the traits show up before the derives I think. |
|
@JelteF such refactoring also discovered an |
src/lib.rs
Outdated
| /// Use it in your import paths, if you don't want to import traits, but only macros. | ||
| pub mod macros { |
There was a problem hiding this comment.
I cannot really think of a reasonable case when users would want this. I think it only clutters the docs. If people really want to do this, they could import a derive directly from derive_more_impl. So I feel we should remove this module. What do you think?
| #[cfg(feature = "from_str")] | ||
| pub use self::r#str::FromStrError; | ||
| #[cfg(feature = $feature)] | ||
| #[doc(hidden)] |
There was a problem hiding this comment.
I really disliked how the standard library trait listing was taking up a third of the front page of the documentation. Especially beacuse they came before the documentation of the actual derives. So I hid them again and I added a small snippet to the README to say that we re-export all traits.
| // all the things from that module into the main module, but we also import our own derive by its | ||
| // exact name. Due to the way wildcard imports work in rust, that results in our own derive taking | ||
| // precedence over any derive from std. | ||
| macro_rules! re_export_traits(( |
There was a problem hiding this comment.
I created a simple macro to generate the boilerplate code.
| @@ -108,27 +108,12 @@ macro_rules! create_derive( | |||
| } | |||
| ); | |||
|
|
|||
| create_derive!("from", from, From, from_derive, from); | |||
There was a problem hiding this comment.
I reorderd these too, to match the ordering in the other files. I think this orderering was simply the order in which the derives were added.
Re-export traits from
stdfor all our derives. This way people don't need to import traits manually when they want to reference them somewhere, such as bounds.Fixes #271