On Mon, 05 Jan 2026 11:29:04 +0100 "Danilo Krummrich" <[email protected]> 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
