Update documentation for arbitrary_enum_discriminant feature

[jswrenn]

Updates documentation to reflect the still unstable arbitrary_enum_discriminantfeature (tracking issue: rust-lang/rust#60553).

[jswrenn]

Thank you so much for your review, @Havvy! If it's alright, I'm going to defer removing the feature flags until this gets a little closer to being merged; otherwise, I can't run mdbook tests.

Terminology

I have a lot of uncertainty about terminology. I only just saw that there's prior agreement (rust-lang/rust#46348, #244) to move away from the term "C-like enumeration" (which I believe is a very poor term) and towards "field-less enumeration". I am thrilled to strike the phrase "C-like" from this PR.

However, using "field-less enumeration" as a synonym for "C-like" isn't quite appropriate.

A C-like enumeration is one in which every variant is unit-like; for example:

enum CLike {
  VariantA,
  VariantB,
  VariantC,
}

All C-like enumerations are field-less, because they cannot include tuple-like or struct-like variants. However, not all field-less enums are are C-like. For instance:

enum Fieldless {
    Unit,
    Tuple(),
    Struct{},
}

This distinction unfortunately (ugh) matters:

1. Only C-like enums may specify explicit discriminant without specifying a repr.
2. Only field-less enums (regardless of whether they're also C-like) may be as-casted to their discriminant values.

It would be nice to have terms to describe both of these sets. My opinion:

• "Field-less" is the right term to describe the set of enums which can be as-casted
• However it cannot then also be used as a synonym for "C-like", so we should identify an alternative term to "C-like" to describe enums in which all variant are unit-like.

[Havvy]

Well, that is quite unfortunate of an edge case. I'm failing to think of any good names.

[ehuss]

@jswrenn Just letting you know that the reference has migrated to mdbook 0.3 (from 0.1). This means that the style of links are slightly different. They should use the .md extension, and are relative to the page they are on (previously they were relative to the root of the book). It looks like this PR should be fairly easy to rebase to resolve the conflicts. Please don't hesitate to ask if you have any questions or any trouble rebasing.

[fee1-dead]

@jswrenn Are you still working on this? If not, I would like to work on it.

[JohnTitor]

~~According to the label, this is waiting for stabilization~~ Oh, I found you posted the report (https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311), nvm!

[jswrenn]

@jswrenn Are you still working on this? If not, I would like to work on it.

I'm not! Go for it!

(Sorry for the delayed reply; I thought I had already replied.)

[ehuss]

Closing as this has been continued by #1055.