Make the PyArray::new method unsafe and document what can and cannot be done with its return value. #220
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.
Luckily, NumPy will always zero-initialize object pointers, c.f. https://github.com/numpy/numpy/blob/84e0707afa587e7655410561324ac36085db2b95/numpy/core/src/multiarray/ctors.c#L826-L835, so that even without invoking
Self::zeros
, the return values ofSelf::new
will always be safe to drop.However their elements will be invalid (null pointers are not valid instances of
PyObject
asPy<...>
is built onNonNull<...>
). Hence the method is markedunsafe
as referencing its elements will invoke undefined behaviour. To actually initialise the elements, the newuget_raw
method is provided (and used internally infrom_iter
,from_exact_iter
,from_vec2
andfrom_vec3
where we currently invoke UB ourselves).Fixes #217