Improve .assume_init() and use Array::maybe_uninit instead of Array::uninitialized #876
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improve
.assume_init()
so that we can see that it is on sound ground (and not transmuting wildly).Then the remaining internal uses of
Array::uninitialized
are removed and replaced withArray::maybe_uninit
.Fixes part of #796
Prerequisite of #804
This pull request demonstrates two different ways of working with
maybe_uninit
. In concatenate and stack,we can see how we're using the more "Rust-level" approach of using regular array traversal and interacting with
elements of type
MaybeUninit<A>
(by just assigning to them, but still).In the implementation of
dot
and the benchmark, we instead use raw array views -RawArrayViewMut
,cast the raw view from element type
MaybeUninit<A>
toA
, and handle the resulting raw view andraw pointers carefully. We have some power in the ndarray abstractions because we can use
Zip
to traverse raw views just like regular arrays.