-
Notifications
You must be signed in to change notification settings - Fork 219
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
MaybeUninit for [Dense]VecStorage? #644
Labels
Comments
See also #634 |
Nice! My issue search fu is weak, and apparently didn't include PRs. Closing this as effectively a duplicate issue, since that PR has more discussion + an actual implementation of switching to MaybeUninit. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Vec::set_len documents a couple of safety requirements, including "The elements at old_len..new_len must be initialized." This is technically violated in a couple of places when inserting after holes:
I'm not entirely sure how bad these violations of the stdlib preconditions are in practice, but they could be resolved by switching these storage impls to use MaybeUninit under the hood, and possibly regular resize fns.
Motivation
Paranoia about UB. As MaybeUninit implies ManuallyDrop, this would also make things a little more drop friendly in the case of VecStorage:
Removing the panic and clean you can also potentially run:
Drawbacks
Unresolved questions
set_len
become "sane" in the presence of MaybeUninit, or wouldv.resize(n, MaybeUninit::uninit())
be required?I'd be willing to implement this, but my profiling-fu for specs is weak.
The text was updated successfully, but these errors were encountered: