Allow fields for ChoiceParameter

[Friendly-Banana]

Would it be possible to have fields in an enum deriving from ChoiceParameter? The fields shouldn't be shown to the user or have any effect on the display, they'd just be there for the programmer.

[kangalio]

Poise needs to create instances of the enum to pass them to the command functions. Which values should the enum fields get, then?

[Friendly-Banana]

Hmm, I see the problem. Maybe the default value? That would require all field types to implement Default.

[kangalio]

I suppose it's possible... but it feels wrong. Do you have an example use case, for example what originally prompted you to create this issue?

[Friendly-Banana]

Yeah, this would be a kind of hacky workaround. I wanted to associate a Colour and an emoji with each state. Having those directly in each enum value is better than having them in separate implementations for the Into trait, though that also works.

#[derive(poise::ChoiceParameter)]
pub enum FeatureState {
    ToDo(i32, Colour, char),
    Implemented(i32, Colour, char),
    Rejected(i32, Colour, char),
    Postponed(i32, Colour, char),
}

[kangalio]

So each variant of FeatureState has an associated i32, Colour and char each? The code snippet you posted is definitely the wrong way to do that. You need a field-less enum that can convert into the associated i32/Colour/char (instead of storing an arbitrary value regardless of variant). That could be done with Into impls, although I personally prefer plain methods, because that's less boilerplate and then you can also name the methods to show the meaning of the i32, Colour and char

[Friendly-Banana]

Oh, yeah makes sense. I guess this issue can be closed then.