derive_more::Error macro collides with local Error enum, whereas thiserror is fine.

[U007D]

Seeing if I can replace thiserror with derive_more:

use derive_more::{Display, Error};

#[derive(Debug, Display, Error)]
enum Error {
    SomeError,
    // ...
}

gives a compilation error (Error is defined twice), whereas thiserror has no problem with the same:

use thiserror::Error;

#[derive(Debug, Error)]
enum Error {
    SomeError,
    // ...
}

compiles fine.

[tyranron]

@U007D please, read the "Re-exports" README section.

This is intentionally and unlikely will be changed. You have 3 ways to handle this:

1. Either import derive_more::Error with renaming:

   use derive_more::Error as StdError;

2. Or import macro only without Error trait:

   use derive_more::derive::Error;

3. Or just rename your Error enum.

For more context, see also:

• new release #259 (comment)
• Re-export traits #273
• re-export traits together with the derive #271 (comment)

It turned out that the case for defining pub struct Error/pub enum Error/pub type Error is very often one. We had tons of such errors in granular modules (like transcoding::Error, command::create_user::Error, etc), and, as the result, the tons of conflicts with use derive_more::Error imports. This lead to a quite refactoring, where in most cases such error types were renamed more precisely, depending on use-case. However, there are still enough places where such renaming is inappropriate or undesired, so we were forced to use use derive_more::Error as StdError imports there, which turned out to be a good practice, though, as it removed any ambiguities regarding [`Error`] references in docs.

[U007D]

I would advocate leaving this as a decision for the user (rather than requiring renaming), but you've clearly considered this and made a call. Thank you for this information.

EDIT: I just read #405 and see you're already thinking about this as well.