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

Tracking Issue for enum_as_repr #86772

Closed
1 of 4 tasks
illicitonion opened this issue Jul 1, 2021 · 3 comments
Closed
1 of 4 tasks

Tracking Issue for enum_as_repr #86772

illicitonion opened this issue Jul 1, 2021 · 3 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@illicitonion
Copy link

illicitonion commented Jul 1, 2021

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

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.
@illicitonion illicitonion added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jul 1, 2021
@HKalbasi
Copy link
Member

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
Copy link
Author

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
Copy link
Member

dtolnay commented Jun 25, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants