Tracking issue for RFC 2363, "Allow arbitrary enums to have explicit discriminants"

This is a tracking issue for the RFC "Allow arbitrary enums to have explicit discriminants" (rust-lang/rfcs#2363).

Steps:

Implement the RFC – Implement arbitrary_enum_discriminant #60732
Adjust documentation (see instructions on rustc-guide)
Stabilization PR – Stabilize arbitrary_enum_discriminant #86860

Unresolved questions:

Should discriminants of enumerations with fields be specified as variant attributes?
Should this apply only to enumerations with an explicit representation?

Mentoring-wise: I'd suggest trying out an example and then tracking down where the error comes from. I don't remember, it's either during parsing or in ast_validation.

Most of the compiler should already support this, where doing the uniform thing is easier.
The "niche" optimization might assume variants with any data have consecutive discriminants, but it should be easy to fix, and we can figure it out after an initial PR is open.

Has anyone stepped up to implement this? If not, I'd like to take a stab.

The current error arises in parsing. I haven't fiddled with it yet, but I suspect a good first step is to remove the else before this if:

rust/src/libsyntax/parse/parser.rs

Lines 7781 to 7789 in 33cde4a

    
           } else if self.eat(&token::Eq) { 
        
               disr_expr = Some(AnonConst { 
        
                   id: ast::DUMMY_NODE_ID, 
        
                   value: self.parse_expr()?, 
        
               }); 
        
               if let Some(sp) = disr_expr.as_ref().map(|c| c.value.span) { 
        
                   any_disr.push(sp); 
        
               } 
        
               struct_def = VariantData::Unit(ast::DUMMY_NODE_ID);

Has anyone stepped up to implement this?

I don't know of anyone

If not, I'd like to take a stab.

Go for it!

I haven't fiddled with it yet, but I suspect a good first step is to remove the else before this if:

That looks like the right start, yes.

@eddyb

I've started work on this here by removing the parsing restriction preventing non-unit variants from having explicit discriminants. As you predicted @eddyb, things seem to basically just work; e.g.:

#![feature(core_intrinsics)]

enum Enum {
  A(u16) = 7,
  B(u32) = 42,
}

fn main() {
  use std::intrinsics::discriminant_value;

  unsafe {
    assert_eq!(discriminant_value(&Enum::A(1)), 7);
    assert_eq!(discriminant_value(&Enum::B(2)), 42);
  }
}

As it stands, adding this feature required removing more lines of code than it involved writing new code! :D

Future work that comes to mind include writing tests and putting this behind a feature flag. Shall I go ahead and file an initial PR?

Sweet! Yes please open a PR with the feature gate and throw some tests in for good measure (there may already be tests checking for the "discriminator values can only be used with a field-less enum" error message, those should now be emitting a feature gate error instead)

Auto merge of #60732 - jswrenn:arbitrary_enum_discriminant, r=pnkfelix

@jswrenn

The #![feature(arbitrary_enum_discriminant)] was implemented on 2019-06-26 in #60732 which was written by @jswrenn and reviewed by @pnkfelix and others.

Documentation

Adjust documentation (see instructions on rustc-guide)

I've submitted a PR to update the reference to reflect this feature (in its current state): rust-lang/reference#639.

I do not believe that either the Book or Rust By Example need updating:

The Book does not mention discriminants at all.
Rust By Example mentions C-like enums, but does not go into their memory layout. Since this feature is only relevant to advance users who care about the memory layout of enums, Rust By Example is probably ill-suited for the topic.

Unresolved Questions

Should discriminants of enumerations with fields be specified as variant attributes?

Presently: no. Discriminants of all types of enumerations are specified with = followed by a constant expression. I implemented this approach because doing so was simplest, but I'd also argue this is the right approach since it means the syntax for specifying discriminants is consistent across variant types.

Should this apply only to enumerations with an explicit representation?

Presently: yes, this feature applies only to enumerations using a primitive representation. Since this feature is only relevant when you care about the precise memory layout of enums, this feature is only reasonable to use when the precise layout of an enum is well-specified.

What are layout guarantees for such enums? Ideally I would like to be able to write code likes this:

#[repr(u8, C)]
enum Foo {
    A = 0,
    B { a: u16 } = 1,
    C { a: u32, b: u16 } = 2,
}

And I want for this type to have exactly the same memory layout as:

#[repr(C)]
struct foo_t {
    pub discr: u8,
    pub payload: foo_u,
}

union foo_u {
    b: u16,
    c: c_t,
}

#[repr(C)]
struct c_t {
    a: u32,
    b: u16,
}

Meaning if repr(C) is used:

Discriminant should always be stored in the beginning.
Discriminant can not be used for niche-optimizations.
Variant fields should follow repr(C).

Having such guarantees would allow in some cases some neat zero-cost translations of C types to safe Rust ones.

@newpavlov

@newpavlov You get most of that (the placement and size of the discriminant) from just #[repr(u8)], I'm not sure if #[repr(C)] adds more to that.

Keep in mind that since your discriminants are the default ones (starting at 0 and adding 1 for each variant), you don't need this feature!

We defined all these back in rust-lang/rfcs#2195, for Servo <-> Firefox I believe.

There are a set of changes related to enums that we need to make, including discriminants, as casts, AsRepr, and similar. Lang has had a design meeting on that, and needs to have another once someone supplies a complete design that fits these pieces together.

Would anyone like to collaborate with me on this design? I'm very familiar with these issues, and have some design sketches on hand, but would love a collaborator help construct a cohesive vision of the future.

Rollup merge of rust-lang#95710 - fee1-dead-contrib:stabilize_arbitra…

I'm going to close as I believe this is now essentially complete as of 1.66.

There might be some longer-term decisions to make around as casting. There are some strange exceptions:

Fieldless enums with variants such as Tuple() or Struct{} allow as casting without a #[repr(…)], and have since 1.15.

// Allowed since 1.15, even without a #[repr]
enum Fieldless {
    Tuple(),
    Struct{},
    Unit,
}
assert_eq!(0, Fieldless::Tuple() as isize);
assert_eq!(1, Fieldless::Struct{} as isize);
assert_eq!(2, Fieldless::Unit as isize);

Similar to above, fieldless enums allow as casting as long as you don't specify an explicit discriminant. Using an explicit discriminant suddenly prevents all as casts.
Fieldless enums allow explicit discriminants on unit variants, but not struct or tuple (new 1.66). It's not clear to me why it was decided to allow this.

#[repr(u8)]
enum FieldlessWithDiscrimants {
    First = 10,
    Tuple(),
    Second = 20,
    Struct{},
    Unit,
}
assert_eq!(10, FieldlessWithDiscrimants::First as u8);
assert_eq!(11, FieldlessWithDiscrimants::Tuple() as u8);
assert_eq!(20, FieldlessWithDiscrimants::Second as u8);
assert_eq!(21, FieldlessWithDiscrimants::Struct{} as u8);
assert_eq!(22, FieldlessWithDiscrimants::Unit as u8);

I suspect further changes may require an RFC or some design decisions with the lang team.

Rollup merge of rust-lang#128795 - zachs18:e0517-update-for-rfc-2195,…

Unrolled build for rust-lang#128795

Navigation Menu

Repository navigation

Tracking issue for RFC 2363, "Allow arbitrary enums to have explicit discriminants" #60553

Documentation

Unresolved Questions

35 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	} else if self.eat(&token::Eq) {
	disr_expr = Some(AnonConst {
	id: ast::DUMMY_NODE_ID,
	value: self.parse_expr()?,
	});
	if let Some(sp) = disr_expr.as_ref().map(\|c\| c.value.span) {
	any_disr.push(sp);
	}
	struct_def = VariantData::Unit(ast::DUMMY_NODE_ID);

Tracking issue for RFC 2363, "Allow arbitrary enums to have explicit discriminants" #60553

Description

Activity

eddyb commented on May 5, 2019

jswrenn commented on May 9, 2019

oli-obk commented on May 9, 2019

jswrenn commented on May 9, 2019

oli-obk commented on May 10, 2019

Centril commented on Jun 25, 2019

jswrenn commented on Jul 14, 2019

Documentation

Unresolved Questions

newpavlov commented on Aug 18, 2019

eddyb commented on Aug 18, 2019

35 remaining items

joshtriplett commented on Jun 15, 2022

jswrenn commented on Jun 15, 2022

ehuss commented on Jan 8, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions