| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
The reference type, `RefBase<A, D, R>`, is parameterized by its element type, a dimensionality type, and its "referent" type. This last type is only a `PhantomData` marker, and acts to differentiate references that are "safe" from those that are "raw", i.e., references that come from an array whose storage is `Data` vs an array whose stoarge is `RawData`. The `DerefMut` implementation contains a check of uniqueness, guaranteeing that an `&mut RefBase` is safe to mutate. This comes with one breaking change and one important internal library note. The breaking change is that `ArrayBase` no longer implements `Copy` for views. This is because a `RefBase` does not know where it is pointing, and therefore cannot implement `Copy`; this, in turn, prohibits `ArrayBase` from implementing `Copy`. Users will now have to explicitly invoke `Clone` in the same way that they do for non-view arrays. The important library note has to do with the `.try_ensure_unique` check that occurs in the `DerefMut` implementation. The library's methods are allowed to *temporarily* break the invariant that an array's `ptr` is contained within `data`. The issue comes when trying to then alter `ptr`, `shape`, or `dim` while that invariant is broken. Code was using `self.ptr = ...` (where `self` is `ArrayBase`), which triggers `DerefMut`, which calls `try_ensure_unique`, which panics on the pointer inbounds check. As a result, code that is altering `RefBase` fields while the array's invariants are broken must be sure to write `self.aref.ptr = ...` instead.
…to RefBase and LayoutRef
…ow to write functionality with the new types
… bullets on the new types
I think I accidentally moved this over to ArrayRef, but we're not sure it should still require DataOwned
|
This is also blocked until the inclusion of the next-gen solver, see rust-lang/rust#80542 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The current reference-to-reference operations defined in impl_ops.rs only allow for outputs where the output type is the same as the left-hand operand. This makes sense for reference-to-owned, where we can reuse an allocation, but not for reference-to-reference.
This is a follow on to #1440, and so cannot be merged until then.