Support an override?

[mqudsi]

Hey, thanks for this crate. I was looking into a lighter alternative to strum and came across it, but I think it's missing one important feature that comes in quite handy (or else I didn't see how to do it in the docs).

It's common to have an enum that can have its Display automatically derived easily:

#[derive(EnumDisplay)]
enum Foo {
    Fox,
    Hen,
}

but then later on to end up with a member that doesn't lend itself to a direct one-to-one mapping between its textual representation and the desired Display output:

#[derive(EnumDisplay)]
enum Foo {
    Fox,
    Hen,
    FoxHound,
}

in which case it would be great if you could just annotate the item in question:

#[derive(EnumDisplay)]
enum Foo {
    Fox,
    Hen,
    #[display("Fox Hound")]
    FoxHound,
}

instead of having to drop EnumDisplay and implement Display yourself.

Is this something you'd consider adding to the crate?

[SeedyROM]

I like this idea! I have another feature PR that was recently suggested here. I feel like this could easily be added to that by just not formatting anything. I also think that the current #[variant_display(...)] name would make more sense as you have it as just #[display] like you suggested. I can make the macro also accept a single argument, since the current setup expects a named param, but doesn't expect any other params!

I need to experiment!

[SeedyROM]

I was able to implement your suggestion in like 20 minutes! 99% of the code was there and I prefer your API idea:

https://github.com/SeedyROM/enum-display/pull/6/files/1bfa469d206c1fa8577d203ad8ff6fd4a03ed967..b0cc81aaf398ba58cbb7deb33db3c032bb71ffde

[SeedyROM]

The feature has been merged into main and will be released in 0.2.0