On Mon, 2026-01-05 at 23:03 +0100, Danilo Krummrich wrote: > On Mon Jan 5, 2026 at 10:11 PM CET, Maurice Hieronymus wrote: > > Before I start implementing, I want to reach common ground. > > > > In my opinion a derive macro which implements Display would be > > perfectly fine, as long as the name suggests what it does. So for > > example #[derive(DisplayEnumVariant)]. This would communicate the > > intent clearly to the user. > > > > Benno, would you be okay with that? If not, Gary and Danilo, are > > you > > fine with the proposed trait implementation (e.g. the variant_name > > function)? > > Actually, it might even be reasonable to have both. In the Nova > driver we have > the case that we want to print the enum variant exactly as it is > defined in the > code and a lowercase version of the enum variant. > > > Are there any common use-cases where one wants to change the case > > of > > the enum variants? If not, I would not implement an argument and > > rather > > name the macro accordingly, so the intent is clear. > > As mentioned above, we do have a case in Nova where we also want a > lowercase > representation to construct a firmware path with.
So there would be the need to have two derive macros: 1. #[derive(DisplayEnumVariant)] Implements Display for all enum variants as they are (original case). 2. #[derive(ImplementVariantName(Case::Lowercase))] Implements the mentioned trait. Case could be an Enum where one could choose between Case::Lowercase and Case::Original. Something along those lines?
