Re: [PATCH v2 1/2] rust: macros: Add derive Display for enums

[Gary Guo <gary@garyguo.net>]

On Mon, 05 Jan 2026 11:29:04 +0100
"Danilo Krummrich" <dakr@kernel.org> wrote:

> On Mon Jan 5, 2026 at 10:02 AM CET, Benno Lossin wrote:
> > On Sun Jan 4, 2026 at 9:07 PM CET, Maurice Hieronymus wrote:  
> >> Add a derive macro that implements kernel::fmt::Display for enums.
> >> The macro outputs the exact variant name as written, preserving case.
> >>
> >> This supports all enum variant types: unit, tuple, and struct variants.
> >> For variants with data, only the variant name is displayed.  
> >
> > I don't think we should be adding this. Display is designed for
> > user-facing output and so it should always be carefully designed and no
> > automation should exist for it.  
> 
> In general I agree, but simple stringification of an enum variant for a Display
> implementation is a very common use-case and it seems pretty unfortunate to have
> to fall back to either do the below (especially if there are a lot of enum
> variants) or having to go the declarative path of doing something as in [1].
> 
> Especially in combination with things like FromPrimitive and ToPrimitive it gets
> us rid of the cases where we need such declarative macro mess.
> 
> Eventually, drivers will most likely implement their own proc macro for this or
> repeat the declarative macro pattern over and over again.
> 
> Maybe we should just pick a more specific name for such a derive macro than
> macros::Display.
> 
> Maybe something along the lines of macros::EnumVariantDisplay? We could also
> have an optional argument indicating whether it should be converted to lower /
> upper case.

I think the proposal is reasonable.

Being able to print enum name is very common and this is why crates like
`strum` exist.

Perhaps if we want to make user having a thought about what names to
expose to users, we can have the case conversion argument be mandatory, so
they are forced to make a choice rather than blindly stuck
`#[derive(Display)]` onto their enum.

Best,
Gary