-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Add "# Safety" and "# Examples" section in std::mem::uninitialized
#151033
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
base: main
Are you sure you want to change the base?
Conversation
Documentation of `std::mem::uninitialized` now have a # Safety section and a # Examples section.
|
Cc @rust-lang/libs for thoughts but I feel like we may not want this. There is never a time when I think that if somebody is interested in the actual semantics here, it's okay for them to read the source code. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Agreed, we should let this deprecated function die. I'm especially wary that explicitly documenting safety conditions is really an API guarantee of sorts, while we really don't want anything that encourages its use. The current ambiguity serves as an additional warning flag not to use it. |
|
I agree with not having an example, but I think listing out safety preconditions is still good (I'd reword them a bit though to clearly discourage use) |
|
@rustbot author If you are still interested in pursuing this, please drop the examples and apply some rewording as Nora suggested. |
|
Reminder, once the PR becomes ready for a review, use |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| /// - `T` must be *valid* with any sequence of bytes of the appropriate length, | ||
| /// initialized or uninitialized. |
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 think we should hint that non-ZST T effectively needs to be all MaybeUninit to account for the uninitialized requirement. Not sure about best wording but maybe something like:
"... That is, if T is not a ZST, it must be MaybeUninit or an ADT containing only MaybeUninit and padding."
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 agree, but wouldn't that suggest a correct usage of this function? I removed that part because it would suggest that using uninitialized() with ZSTs is acceptable (and you said that we should discourage usage of uninitialized() by not providing any example, that's why I kept the safety conditions a bit more "abstract"). What do you think?
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 think mentioning the MaybeUninit requirement suggests anything more than what is already there, just makes it more obvious that this isn't sound even for POD types (since that's been a confusion point in the past). Not mentioning ZSTs seems reasonable though.
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☔ The latest upstream changes (presumably #151634) made this pull request unmergeable. Please resolve the merge conflicts. |
This PR improves documentation to
std::mem::uninitialized. While the function is deprecated, it currently lacks a formal # Safety section and clear examples on how to use it, even if it is almost always UB.