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

[Centril]

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:

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

[eddyb]

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.

[jswrenn]

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);

[oli-obk]

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.

[jswrenn]

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?

[oli-obk]

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)

[Centril]

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