Repository navigation
Support an override? #7
Description
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?
Activity
SeedyROM commentedon Aug 1, 2025
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 commentedon Aug 1, 2025
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 commentedon Oct 1, 2025
The feature has been merged into main and will be released in
0.2.0