Skip to content
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

Merged
merged 1 commit into from
Nov 19, 2024

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Oct 9, 2024

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

@RalfJung
Copy link
Member Author

@rust-lang/opsem could someone take a look at this so we can get it merged? :)

Comment on lines +305 to +307
- one variant has a single field with a type that guarantees discriminant
elision (to be defined below), and
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

@RalfJung RalfJung Nov 16, 2024

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.

Copy link
Member

@saethlin saethlin Nov 16, 2024

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.

Copy link
Contributor

@chorman0773 chorman0773 Nov 17, 2024

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.

Copy link
Member Author

@RalfJung RalfJung Nov 17, 2024

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.

@saethlin
Copy link
Member

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.

@saethlin
Copy link
Member

I don't know which of the merge buttons you want to use here, so I'll let you merge this :)

@RalfJung RalfJung merged commit f572fa7 into rust-lang:master Nov 19, 2024
2 checks passed
@RalfJung
Copy link
Member Author

I see only one merge button?^^ :)

@RalfJung RalfJung deleted the option-like branch November 19, 2024 06:42
@ia0
Copy link

ia0 commented Nov 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants