Add impl TryFrom<T> for E where E is a C-like #[repr(T)] enum

[canndrew]

This is a problem that has come up a lot. The most recent discussion I could find about it is the internals thread here, but that thread has been locked and I figured this should probably have an "official" issue somewhere.

There's currently no (good) way to convert from an enum integer discriminant value to the enum itself. Enums should support deriving TryFrom for this purpose. eg.

#[repr(u32)]
#[derive(TryFrom)]
enum MyCoolEnum {
    Foo = 1,
    Bar = 2,
}

let x: u32 = ... ;
let my_cool_enum = MyCoolEnum::try_from(x).expect("invalid discriminant!");

[RustyYato]

This would be a breaking change to add now that TryFrom is stable.

[Centril]

@KrishnaSannasi Can you elaborate as to why that is the case?

[RustyYato]

I'm sorry, I missed the derive. My bad and sorry for the noise. This looks good.

[SimonSapin]

This was easy enough:

macro_rules! enum_try_from_int {
    (
        #[repr($T: ident)]
        $( #[$meta: meta] )*
        $vis: vis enum $Name: ident {
            $(
                $Variant: ident = $value: expr
            ),*
            $( , )?
        }
    ) => {
        #[repr($T)]
        $( #[$meta] )*
        $vis enum $Name {
            $(
                $Variant = $value
            ),*
        }

        impl std::convert::TryFrom<$T> for $Name {
            type Error = ();

            fn try_from(value: $T) -> Result<$Name, ()> {
                match value {
                    $(
                        $value => Ok($Name::$Variant),
                    )*
                    _ => Err(())
                }
            }
        }
    }
}

enum_try_from_int! {
    #[repr(u32)]
    #[derive(PartialEq)]
    pub enum Foo {
        Bar = 4,
        Baz = 7,
    }
}

pub fn main() {
    use std::convert::TryFrom;
    assert!(Foo::try_from(7).unwrap() == Foo::Baz)
}

But yeah it would be nicer as a derive proc macro. It’s debatable whether this should be in the standard library rather than crates.io, but I personally wouldn’t be opposed.

[Centril]

I personally think (as a general principle) that whatever crate provides the trait should also provide the derive macro (well, they cannot be the same crate exactly, but the same project) if a reasonable implementation can be given. In the case of the standard library it would be the language that should provide said derives when structural impls can be given.

[canndrew]

If I make a PR for this is it likely to get merged?

[Centril]

It's probably a large enough addition to the language to be RFC-worthy. I think we should also consider adding derives more holistically rather than a one-off.

[bluss]

I don't know the details of proc macros that well, will the derive always see the repr attribute, or is there an ordering issue?

[carbotaniuman]

@Centril Why does adding a simple Trait to an object require an entire RFC?

[Centril]

Well it's adding a general mechanism for deriving, not one specific object, and it is a language change that needs some design work so an RFC seems appropriate.

[SimonSapin]

Doesn’t the #[derive(…)] mechanism already exist?

[Centril]

I think I phrased that poorly... Maybe "general" was too general here. I really meant specifically adding derive(TryFrom) to the language as opposed to adding one implementation to one type.

@canndrew Let's check the mood? cc @rust-lang/lang.

@bluss I believe that if #[repr(...)] is in front of the #[derive(...)] then it will be seen by it, but let's cc @petrochenkov.

[SimonSapin]

#[proc_macro_derive] is already part of the language, so this would be adding one procedural macro to the standard library.