You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rust 1.25 introduces a NonNull type, which represents a pointer that must always be non-null. It would be nice to switch the ArrayBase.ptr field to type NonNull<S::Elem> to indicate that the pointer must always be non-null.
However, I'm not quite sure about the implications of NonNull<T> being "covariant over T". After reading this page in the nomicon, I think this is okay for Array, ArrayView, ArrayViewMut, and ArcArray, but I'm not sure that it's okay in general for arbitrary S: Data.
Sure, using NonNull should be good for us, don't see a problem with that. We need to remember to highlight the non-null requirement in ArrayView::from_shape_ptr. I'll have a think about if we already de facto require that pointer to be non-null (it certainly is non-null in all the safe ways of making an ArrayView).
Specifically, I'm thinking about the raw pointer array views we discussed in #388, for which NonNull might not make sense. There may also be other Data types that we want to add in the future.
Activity
bluss commentedon Apr 1, 2018
Sure, using NonNull should be good for us, don't see a problem with that. We need to remember to highlight the non-null requirement in
ArrayView::from_shape_ptr. I'll have a think about if we already de facto require that pointer to be non-null (it certainly is non-null in all the safe ways of making an ArrayView).bluss commentedon Apr 1, 2018
NonNull was already listed over in #414, but I updated it to link to this issue as the specific one for that point.
bluss commentedon Apr 1, 2018
(There is no “arbitrary S: Data” yet, because the Data trait is documented to be for our own purpose and we control all its implementations.)
jturner314 commentedon Apr 12, 2018
Specifically, I'm thinking about the raw pointer array views we discussed in #388, for which
NonNullmight not make sense. There may also be otherDatatypes that we want to add in the future.