Repository navigation
Change uninitialized to return an array of MaybeUninit #685
Description
Activity
Internally I'd kind of just like a
Zipwith ndproducers that would give out raw pointers to the elements (so that we avoid references and iteration is sound). That way we can use uninitialized or similar correctly using some raw pointer code, at least.I'm not sure the recipe in the title of this issue is what we should do - there might be better ways to do it, for example to provide raw pointer traversals
Can we explain why
Array1::<bool>::uninitialized(2)is UB? What's the difference toVec::<bool>::with_capacity(2)?To me it looks like it can't be UB, on its own, but further method calls would be needed.
Maybe this comment can back me up rust-lang/rust-clippy#4483 (comment)
Edit: I have a tentative conclusion,
Array1::<bool>::uninitialized(2)in itself is ok. However, if this array drops without being initialized, the&mut [bool]created in the methodVec::dropis not valid, and that's the reason this is a very hard API to work with (and it is not really panic safe, as was intended, even though it does not seem to have ill effects today. Meanwhile, I've even proposed a PR to rust to fix Vec::drop to not make a mutable slice in drop.)
The
.uninitialized()method onArrayBasehas some issues. For example,Array1::<bool>::uninitialized(2)is undefined behavior.Rust 1.36 added
std::mem::MaybeUninitfor safer handling of uninitialized data. We should replace the existing.uninitialized()method onArrayBasewith one that returns an array ofMaybeUninitinstances. We then need to add the necessary methods to cleanly work with arrays like this (e.g. an array-level equivalent ofassume_init).