-
Notifications
You must be signed in to change notification settings - Fork 59
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 the docs for layout guarantees of option-like enums #538
Conversation
@rust-lang/opsem could someone take a look at this so we can get it merged? :) |
- one variant has a single field with a type that guarantees discriminant | ||
elision (to be defined below), and |
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.
Restricting the definition of an option-like enum based on the type of the single field is quite strange to me. Because I'd think that excludes Option<T>
from the definition, because T
could be usize
or any type without guaranteed discriminant elision.
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.
Option<usize>
is indeed excluded. Option<NonZeroUsize>
is included.
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.
@saethlin does this answer your question? I don't think I quite understood the comment, TBH.
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.
Whoops, I didn't notice you'd responded.
The text here is just confusing to me, because what I'm imagining is a reader saying "Is this an option-like enum?":
enum Thing<T> {
Yes(T),
No,
}
Because by the text above, Thing<T>
is not "an option-like enum" because its single field does not guarantee discriminant elision. This would be though:
enum Thing {
Yes(NonZeroUsize),
No,
}
...but directly below this the reference already says that Option<T>
is an example of an option-like enum.
🤷
I think you're making an assumption that the reader will interpret words a bit differently when a generic parameter is included. If other can confirm that they have read this and don't find the wording confusing I'm happy to be overruled.
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 reason, in my type-layout docs PR, I chose to separate the idea of "Is an enum for which discriminant elision may apply" (in my text, called a discriminant elision elible) and "A field of this type is subject to discriminant elision" (called elision candidate type). When the two are combined is when the result is guaranteed.
I also note explicitly that the determiniation is post-mono. and explicitly call out both Option<T>
and Result<T,E>
.
So the first Thing<T>
would be a discriminant elision eligible enum, and its elision candidate field is of type T
. if we then substitute in T=NonZeroUsize
, the layout guarantees would apply, but substituing in T=usize
, and it would not.
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 am implicitly assuming that we are talking about a fully monomorphic type here. It doesn't make sense to ask about the layout of a generic type. I can make that more explicit (though this may come at the cost of readability). I don't see how splitting this concept into two separate concepts is helpful.
e401446
to
1f0ebd0
Compare
The definition at the top is at least something to point to. I'm still not enthused about the wording, but I think it's better to merge this and wait for someone to actually be confused than continue to haggle over it. |
I don't know which of the merge buttons you want to use here, so I'll let you merge this :) |
I see only one merge button?^^ :) |
I guess the question was between merge, rebase, and squash (all sharing the same button using a drop down for selection). But given the git history and how this PR was merged, the answer was indeed merge 😅 This can be enforced with a branch rule if needed, such that only one option is available in the drop down, making such question automatically answered in the future. |
This updates our docs to match the FCP in rust-lang/rust#130628. The UCG reference has been a valuable resource for figuring out what is and is not guaranteed about layout, so it seems worth keeping it up-to-date.
(Medium-term, I expect this to be superseded by @chorman0773's new layout chapter for the reference, but we're not there yet.)