RFC: Add a special TryFrom and Into derive macro, specifically for C-Style enums

[agreyyy]

I think this a good quality of life proposal similar to the proposal to add a derive Default for enums, not big in scope or magnitude.
TLDR:
I want to make a derive macro for TryFrom and Into, that generate an impl of TryFrom and Into for any C-Style Enum:

//using these two macros
#[derive(FromInt, IntoInt)] // names subject to change
enum CStyleEnum {
   Variant1 = 10,
   Variant2 = 20,
   ...
}

//convert from a number to the C-style enum easily
let from_num = CStyleEnum::try_from(10); // Ok(CStyleEnum::Variant1)
let failed_from = CStyleEnum::try_from(21); // Err(())
//convert into a number from a C-style enum more generically
let into_num = CStyleEnum::Variant2.into(); //20

Rendered

[kennytm]

What do you mean by "niche" here? Isn't being niche (i.e. very specialized), plus having a library alternative, exactly why this feature should not be standardized into the language?

[kennytm]

Note that the RFC itself can already been done with the num_enum package (and tons of other alternatives).

---
[dependencies]
num_enum = "0.7.2"
---

use num_enum::{TryFromPrimitive, IntoPrimitive, TryFromPrimitiveError};

#[derive(TryFromPrimitive, IntoPrimitive, PartialEq, Debug)]
#[repr(i32)]
enum CStyleEnum {
    Variant1 = 10,
    Variant2 = 20,
}

fn main() {
    assert_eq!(CStyleEnum::try_from(10), Ok(CStyleEnum::Variant1));
    assert_eq!(CStyleEnum::try_from(21), Err(TryFromPrimitiveError { number: 21 }));
    assert_eq!(i32::from(CStyleEnum::Variant2), 20);
}

Unlike #3107 about #[derive(Default)], the standard library did not have #[derive(TryFrom, Into)] already.

---

For non-C-style enums, the derive_more package provided #[derive(From, TryInto)] which is based on shape rather than discriminant.

#[derive(From, Debug)]
#[repr(i32)]
enum NotReallyCStyleEnum {
    A = 10,
    B(i32) = 20,
}

fn main() {
    dbg!(NotReallyCStyleEnum::try_from(10_i32)); // B(10), not A
}

[clarfonthey]

While I would like to see From and TryFrom derives supported by the standard library, I have to admit that so many crates exist to do this and it's going to take a very robust proposal to accomplish this.

This isn't saying that your proposal is bad, genuinely, just that the bar is extremely high for this IMHO. Since we can't really change what the shape of the standard library version would be once stabilised, we're going to need a very solid crate implementing exactly what form this should take, and see it widely used before any standard library version is likely to get added.

I like derive_more, but as mentioned, its functionality is split with stuff like num_enum, and it's not clear how From and TryFrom should be derived in all cases. Again, we need a very comprehensive proposal to make it in the standard library, and right now we just have several perfectly reasonable proposals who aren't as comprehensive, which is fine since they're in separate crates and people can use what they need.

[ehuss]

I'm tentatively marking this t-libs-api, but I don't actually know if that's the right team assignment.

It does seem like there is a lot of background and prior-art that isn't mentioned in the RFC. For example, this has been brought up in #2783 and https://internals.rust-lang.org/t/derive-tryfrom-for-c-like-enums/12940 among other places.

[jswrenn]

It's very unusual for derive(XXX) to actually derive YYY. Why are you leaning towards having the derive TryFromInt emit an implementation of TryFrom? Why not call the derive TryFrom?

[jswrenn]

I think that this code all logically makes sense and there is really no other way I can think of to implement TryFrom for a C-style enum

I can think of plausible alternative implementations. Consider that Rust draws a subtle distinction between an enum's discriminant (which is the logical value associated with a variant) and its tag (which is the actual in-memory value used to distinguish it from other variants. An enum can have a discriminant but no tag, or a discriminant that's a different value from its tag, or a discriminant that's a different type from its tag. For instance, the Variant below has a logical discriminant of -42isize, but no tag at all:

enum Example {
    Variant = -42
}

In any case where the tag is different from the discriminant, what should the behavior of this derive be? Your RFC leans towards following the value (but not necessarily the type) of the discriminant, but that's not the only plausible implementation.

[jswrenn]

I want to propose a TryFrom<{Integer}> and Into<{Integer}> derive macro becomes available for all C-style enums.

The term "C-style enum" is ill-defined in Rust. We use either:

• "fieldless enum" for an enum where no variant has fields
• "unit-only enum" for an enum where all variants are unit-like

See the reference for more information: https://doc.rust-lang.org/reference/items/enumerations.html

[jswrenn]

For field-less (but not unit-only) enums, this will produce incorrect results. Consider this:

enum Example {
  Foo
  Bar {}
  Baz()
}

Baz as {integer} will produce not the discriminant of Baz, but rather the address of its implicit constructor.

[jswrenn]

I don't see many APIs that consume impl Into<u8>. Is there an instance where such an API would be useful for a type like DNSOpCode?

[matklad]

See also rust-lang/rust#86772