Add #[derive] on C-like enums for From impls from the various numeric types

[lilyball]

C-like enums used to be able to say #[derive(FromPrimitive)] to allow for converting from integral types into enum variants. This no longer works as std::num::FromPrimitive has been removed (see #24822).

It seems reasonable to say that the "correct" replacement is From impls for various integral types. It would be great if we could derive those impls. #[derive(From)] is perhaps a bit non-obvious as to what it's supposed to be deriving. I'd like to be able to say #[derive(From<i32>)], but that's not valid syntax.

Given that, either the attribute syntax should be extended to allow for <> in identifiers (it should perhaps allow for any well-formed types), or a more conservative approach would be to make #[derive(From(i32))] work instead (which is valid syntax but aborts in the derive machinery, saying the attribute is malformed). Since the current derive approach converts #[derive(Foo,Bar)] into #[derive_Foo] #[derive_Bar] this could be accomplished by converting #[derive(From(i32))] into #[derive_From(i32)].

Ideally there'd be some way to say "derive From<T> for all integral types", since FromPrimitive allowed for converting from all integral types, but I'm not certain how that should work. With the more conservative approach we could just pick an identifier and say something like #[derive(From(raw))], but that's not very discoverable.

[lilyball]

We may also want to consider being able to derive Into for the numeric types as well, although that's not as interesting because the enum variants can be converted into integral types with as (but it's still potentially useful).

Note that we can't derive From<T> for i32, which would be preferred, as that requires T to be public and I'm not aware of any precedent for #[derive] only working on public types. But that restriction doesn't apply to Into, so we can derive e.g. Into<i32> just fine.

[steveklabnik]

Triage: almost two years later, custom derives are almost here on stable. That said, this sounds like a question for @rust-lang/libs ; I'd assume this would use TryFrom today, given that it's a fallible operation.

[Mark-Simulacrum]

Closing -- I believe this should be implemented out-of-tree with Macros 1.1 if we want it. If you disagree, then this needs to go through the RFC process, so please follow that.