Tracking Issue for enum_as_repr

[illicitonion]

Feature gate: #![feature(enum_as_repr)]

This is a tracking issue for traits to convert primitive enums into their repr (core::enums::AsRepr), and attempt to convert reprs into primitive enums (core::enums::FromRepr). AsRepr is automatically implemented for all relevant enum types, as well as std::mem::Discriminant, and FromRepr may be derived.

Public API

// core::enums

// Automatically implemented for all data-free enums with an explicit repr attribute.
pub unsafe trait AsRepr: Sized {
    type Repr;
    fn as_repr(&self) -> Self::Repr;
}

pub unsafe trait FromRepr: AsRepr {
    fn try_from_repr(from: Self::Repr) -> Result<Self, TryFromReprError<Self::Repr>>;
    unsafe fn from_repr(from: Self::Repr) -> Self;
}

Steps / History

• Discussed as part of RFCs 3040 and 3046
• Implementation: Automatically implement AsRepr and allow deriving FromRepr for fieldless enums #81642
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Do we want a blanket impl of FromRepr for Discriminant<T>? We want to consider carefully if that impl would have unwanted semver implications.

[HKalbasi]

In this blog post author mentions a problem about optimizing by specialization doesn't cover wrapper types so wrapper types aren't truly zero cost. Can trait AsRepr solve this problem? I mean, instead of implementing specializations on u8 directly, implementing it on AsRepr<Repr=u8> so wrapper types and enums can take benefits. Is it possible/cost effective?

Sorry if it is discussed before, I didn't read all of threads related to this.

[illicitonion]

That's an interesting thought! There have been three iterations of this feature:

1. Just implement TryFrom/TryInto for enums - that definitely doesn't give enough information about representation to solve that problem
2. Add a new very general trait IntoUnderlying and implement it for enums, and potentially other types such as repr(transparent) types - that would be a fairly natural basis for the kind of specialisation you describe.
3. Add a less general trait AsRepr and implement it for enums and nothing else. This feels like it could be the basis for the specialisation you describe, but it'd be fairly limited - while one could theoretically implement core::enums::AsRepr for arbitrary newtype wrappers, it would feel a bit weird, mostly because of the enums in the package name. But that narrowing from IntoUnderlying to AsRepr was a conscious choice, I think to be explicit about a reduced surface area of the feature.

Possibly TransmuteInto and TransmuteFrom from the safe transmute project could be better fits as wrapper-type specialisation targets? Or perhaps this is motivation to introduce the IntoUnderlying trait proposed in rust-lang/rfcs#3046 (possibly alongside AsRepr, with a blanket impl) to handle the transparent wrapper case? (cc @jswrenn)

[dtolnay]

The implementation of this feature never ended up being merged. I'll close the tracking issue since it isn't currently tracking anything, but we can reopen (or open a different one) if someone picks this work back up.