Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EnumDiscriminants: can't infer type #317

Closed
wiiznokes opened this issue Dec 3, 2023 · 3 comments
Closed

EnumDiscriminants: can't infer type #317

wiiznokes opened this issue Dec 3, 2023 · 3 comments

Comments

@wiiznokes
Copy link

I don't understand why I can't convert my enum into a discriminant. Here is the code:

#[derive(Debug, Clone, EnumDiscriminants)]
pub enum NodeType {
    Control(Control),
    Fan(Fan),
    Temp(Temp),
    CustomTemp(CustomTemp),
    Graph(Graph),
    Flat(Flat),
    Linear(Linear, LinearCache),
    Target(Target, TargetCache),
}

if node.node_type.into() == NodeTypeDiscriminants::Control {
   return Err(UpdateError::InvalidControl);
}
error[E0282]: type annotations needed
   --> data\src\update.rs:153:47
    |
153 | ...                   if node.node_type.into() == NodeTypeDiscriminants::Control {
    |                                         ^^^^
    |
help: try using a fully qualified path to specify the expected types
    |
153 |                             if <NodeType as Into<T>>::into(node.node_type) == NodeTypeDiscriminants::Control {
    |                                ++++++++++++++++++++++++++++              ~

For more information about this error, try `rustc --explain E0282`.

So, why not make an helper function, like node_type.to_discriminant() ?
This will be a little more descriptive than into(), and will provide a similar alternative to into() in case of compiler problems.

@wiiznokes
Copy link
Author

Moreover, into to take ownership of the variable while it seems unnecessary.

@wiiznokes
Copy link
Author

I'm forced to call NodeTypeDiscriminants::from(&node.node_type)

@Peternator7
Copy link
Owner

Hey @wiiznokes, naming things is hard so I try to avoid inherent methods on types. There's an infinite number of valid/useful names, I try to use the built-in traits from the standard library and then allow people to add their own inherent methods on top of it if they want to. It's not ideal, but it's the best compromise I can find between flexibility and causing a combinatorial explosion in the api surface of this crate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants