Add a new intrinsic, discriminant_value that extracts the value of the discriminant for enum types.
Many operations that work with discriminant values can be significantly improved with the ability to extract the value of the discriminant that is used to distinguish between variants in an enum. While trivial cases often optimise well, more complex ones would benefit from direct access to this value.
Which is compiled into this IR.
A discriminant is a value stored in an enum type that indicates which variant the value is. The most common case is that the discriminant is stored directly as an extra field in the variant. However, the discriminant may be stored in any place, and in any format. However, we can always extract the discriminant from the value somehow.
C-Like Enum Type: If no variants have fields, then the enum is considered "C-Like". The user is able to specify discriminant values in this case, and the return value would be equivalent to the result of casting the variant to a u64.
The value returned for the same variant of the same enum type will compare as equal. I.E. discriminant_value(v) == discriminant_value(v).
Two values returned for different variants will compare as unequal relative to their respective listed positions. That means that if variant A is listed before variant B, then discriminant_value(A) < discriminant_value(B).
Note the returned values for two differently-typed variants may compare in any way.
Potentially exposes implementation details. However, relying the specific values returned from discriminant_value should be considered bad practice, as the intrinsic provides no such guarantee.
Allows non-enum types to be provided. This may be unexpected by some users.
More strongly specify the values returned. This would allow for a broader range of uses, but requires specifying behaviour that we may not want to.
Disallow non-enum types. Non-enum types do not have a discriminant, so trying to extract might be considered an error. However, there is no compelling reason to disallow these types as we can simply treat them as single-variant enums and synthesise a zero constant. Note that this is what would be done for single-variant enums anyway.
Do nothing. Improvements to codegen and/or optimisation could make this uneccessary. The "Sufficiently Smart Compiler" trap is a strong case against this reasoning though. There will likely always be cases where the user can write more efficient code than the compiler can produce.
Should #[derive] use this intrinsic to improve derived implementations of traits? While intrinsics are inherently unstable, #[derive]d code is compiler generated and therefore can be updated if the intrinsic is changed or removed.
Using bounds such as T:Reflect to help ensure parametricity.
Do we want to change the return type in some way?
It may not be helpful if we expose discriminant directly in the case of (potentially) negative discriminants.
We might want to return something more opaque to guard against unintended representation exposure.
Does this intrinsic need to be unsafe?