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

Support Into/From trait #163

Open
vic1707 opened this issue Feb 10, 2025 · 3 comments · May be fixed by #164
Open

Support Into/From trait #163

vic1707 opened this issue Feb 10, 2025 · 3 comments · May be fixed by #164
Labels
C-enhancement Category: A new feature or an improvement for an existing one

Comments

@vic1707
Copy link

vic1707 commented Feb 10, 2025

Assuming all code paths implements the same Into/From "destination" it could be nice to let auto_enums generate those traits impls.
This can, I think, theorically be done in the custom derive attribute, keeping existing functionality as they are.

use auto_enums::auto_enum;

struct Toto(u64);
impl <T: Into<u64>> Into<Toto> for T {
    // ...
}

#[auto_enum(Into<Toto>)]
fn example(x: u8) {
    match x {
        0 => 12_u8,
        1 => 42_u16,
        _ => 69_u64,
    }
}

Where the generated code would look like

impl Into<Toto> for $enum_name {
    fn into(value: $enum_name) -> Toto {
        // simply blindly call .into() for each arm
    }
}

Oversimplified code but I think everyone reading this gets the idea.

Would you be open to a PR for this?

@taiki-e
Copy link
Owner

taiki-e commented Feb 10, 2025

It seems that supporting Into/TryInto is fine. I would accept a PR to do that.

@taiki-e taiki-e added the C-enhancement Category: A new feature or an improvement for an existing one label Feb 10, 2025
@vic1707
Copy link
Author

vic1707 commented Feb 10, 2025

Thanks, I'll start to work on Into that soon ™️ 👌
As for TryInto (which I'll probably do in a 2nd PR) how do you think the error type should be treated?

Should it be named enum_derive(TryInto<Target, CustomError>)?
Should it be extracted from the first variant error type for its TryInto<Target> implémentation (kinda like what's done with the Future trait?
Both (allow naming, if missing auto-extract)?

Naming it has the advantage to allow users to have their match arms yield a different Error type and capturing it all by -> impl TryInto<Target, Error=CustomError>

@taiki-e
Copy link
Owner

taiki-e commented Feb 10, 2025

As for TryInto (which I'll probably do in a 2nd PR) how do you think the error type should be treated?

Should it be named enum_derive(TryInto<Target, CustomError>)? Should it be extracted from the first variant error type for its TryInto<Target> implémentation (kinda like what's done with the Future trait? Both (allow naming, if missing auto-extract)?

Oh, that is indeed tricky. It might make sense to skip TryInto for now.

@vic1707 vic1707 linked a pull request Feb 12, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: A new feature or an improvement for an existing one
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants