-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update documentation for arbitrary_enum_discriminant feature #639
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of good work. ❤️
Lots of little changes requested; a couple bigger ones.
<ol> | ||
<li> | ||
|
||
if the enumeration is "C-like" (i.e., it has no tuple or struct variants); e.g.: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the enumeration is "C-like" (i.e., it has no tuple or struct variants); e.g.: | |
if the enumeration is field-less. For example: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per #639 (comment), these terms may not be truly interchangeable.
if the enumeration is "C-like" (i.e., it has no tuple or struct variants); e.g.: | ||
|
||
```rust | ||
# #![feature(arbitrary_enum_discriminant)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feature flags aren't needed; the prose will only be merged after the feature is stable.
# #![feature(arbitrary_enum_discriminant)] |
|
||
#### Casting | ||
|
||
If there is no data attached to *any* of the variants of an enumeration, then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need to describe a field-less enum here. Just use the term.
If there is no data attached to *any* of the variants of an enumeration, then | |
If the enum is a field-less enum, then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per #639 (comment), these terms may not be completely interchangeable. If "field-less" is meant to be synonymous to "C-like", then this change would be incorrect.
If there is no data attached to *any* of the variants of an enumeration, | ||
then the discriminant can be directly chosen and accessed. | ||
Each enum instance has a _discriminant_: an integer logically associated to it | ||
that is used to determine which variant it holds. An opaque reference to this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using mem::discriminant
should be in the accessing the discriminant section.
integer associated to it that is used to determine which variant it holds. An | ||
opaque reference to this discriminant can be obtained with the | ||
[`mem::discriminant`] function. | ||
called an enum variant. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The re-organization looks fine, but we lose our definition of a field-less enum. This suggestion re-adds it. I don't actually know if the anchor actually works. It should just create an anchor that can be linked too without changing any styles or making it clickable.
called an enum variant. | |
called an enum variant. | |
An enum where no constructors contain fields are called a *<a name="field-less-enum">field-less enum</a>*. |
if a [primitive representation] is used; e.g.: | ||
|
||
```rust | ||
# #![feature(arbitrary_enum_discriminant)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feature flag not needed.
# #![feature(arbitrary_enum_discriminant)] |
an `isize` value. However, the compiler is allowed to use a smaller type (or | ||
another means of distinguishing variants) in its actual memory layout. | ||
|
||
If the [primitive representation] or the [`C` representation] is used, the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what this paragraph is trying to say.
leading bytes of a variant (e.g., two bytes if `#[repr(u16)]` is used), will | ||
correspond exactly to the discriminant. | ||
|
||
### Assigning Discriminant Values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this entire section, it only makes sense for field-less enums or enums with a primitive representation (or the C
representation?). The way it is written, it seems like explicit discriminants are only for those and implicit applies to all. Instead, it should state that having a non-opaque (feel free to pick a different descriptor) discriminant applies in those situations and in all others, it is opaque and must only be accessed via mem::discriminant
.
Co-Authored-By: Ryan Scheel <[email protected]>
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 TerminologyI 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:
It would be nice to have terms to describe both of these sets. My opinion:
|
Well, that is quite unfortunate of an edge case. I'm failing to think of any good names. |
@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 |
@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.) |
Stabilize `arbitrary_enum_discriminant` Closes rust-lang#60553. ---- ## Stabilization Report _copied from rust-lang#60553 (comment) ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously, this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0, B(i8) = 1, C(bool) = 42, } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md), this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant), there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](rust-lang#70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](rust-lang#60732) added documentation to the Unstable Book, rust-lang/reference#1055 was opened as a continuation of rust-lang/reference#639. ### Resolution of unresolved questions The questions are resolved in rust-lang#60553 (comment). ---- (someone please add `needs-fcp`)
Closing as this has been continued by #1055. |
Updates documentation to reflect the still unstable
arbitrary_enum_discriminant
feature (tracking issue: rust-lang/rust#60553).