discriminant_value intrinsic -- tracking issue for 639

[nikomatsakis]

Tracking issue for rust-lang/rfcs#639.

Some things to nail down before stabilization:

• prototype implementation
• signature needs to have a <T:Reflect> bound
• documentation should reflect the inherent instability in this value and describe valid uses
• perhaps signature should require input T to actually be an enum instance?
• do we want to adjust the return type in any way to enforce the above rules?

[pnkfelix]

The prototype implementation at #20907 is very easy to rebase (I have already done so). I plan to land that prototype as part of work towards #15523

[pyfisch]

How is the progress here? I want to use it in a package, but I don't think it will be 1.0, right? Will it be included in 1.1?

[briansmith]

RE the documentation issue: The value wouldn't be unstable for the case of a C-like enum, so the statement about the value being unstable should be qualified as such. And, it would also be useful to document that this feature can/should be used instead of as for safer conversions of C-like enums. A new lint that does that would be great.

However, the RFC says that the type is always u64 which means that I'd have to use as in my code anyway, as I need u8-typed discriminant values (e.g. for parsing ASN.1). Accordingly, I think that the part of the design where the return type is fixed at u64 should be fixed.

[durka]

I previously suggested a way to solve the return type problem: introduce a trait instead of (or in addition to) the intrinsic function.

trait MagicEnumTrait {
    type Repr;
    fn value(&self) -> Self::Repr;
}

This trait would be auto-implemented for every enum and Repr defined to be the type of the discriminant (in case the discriminant is packed away, Repr is the smallest integer type with enough bits). Also, Repr corresponds to the signedness of the enum in the case of things like #[repr(i8)] which makes it easier to compare discriminants for ordering.

[SimonSapin]

For Stylo we want to build with a stable Rust compiler. For Servo’s style crate, the only thing missing is discriminant_value. (servo/servo#11816)

We use it with an enum that represents a property declaration: there’s one variant per supported CSS property, and each variants has a field with the property value. (The Rust types for values can be different for each property.) During the cascade, we get an sequence of declarations ordered by precedence, and we want to only keep one per property. We use discriminant_value to determine which property a given enum value represents.

There’s already some code generation going on in this crate, so we could write a function or method that behaves similarly to discriminant_value and uses match internally, but I don’t know if this would optimize as well. (This is used in a hot loop.)

[ranma42]

@SimonSapin if the results of the internal function are exactly the same as discriminant_value, LLVM should be able to optimise away the match completely and replace it with the same memory load that would be performed by discriminant_value. This has worked for me with several C-like enums (hand-checking the assembly output), so this might be a viable alternative if you do not want to wait for the stabilisation. Nonetheless I would recommend to verify if LLVM optimisations also work as intended in your case.

[SimonSapin]

These enums are not C-like though, otherwise I could use enum_value as usize. I’ll try it anyway.

[pnkfelix]

My questions at this point:

• has the signature of the intrinsic gotten a bound, as listed as a work item in the description by Niko?
  • my understanding is that the answer here is "no."
• should we provide a stable function that is merely a shim over the existing intrinsic, or should we hold off stabilization in order to attempt to implement some way to vary the return type based on the particular enum (which has been discussed previously, including in the comments here).
  • I'm personally ambivalent here; I can see the motivation to stabilize the thing we have, but I also respect people concerned about prematurely stabilizing before exploring the alternatives.
• if we decide to hold off stabilization to explore an alternative API: do such alternatives require a new RFC (or at least RFC amendment)?
  • I think the answer here is "yes."