qcell
qcell copied to clipboard
uazu
Statically-checked alternatives to RefCell and RwLock
Personally, I don't think that this is required. All the cases so far where I've needed simultaneous borrows have been handled by `rw2`. However if there are any concrete cases...
Here's another idea I had. There are the existing functions on cell owners `rw`, `rw2`, and `rw3`, which can borrow multiple cells at a time, but that method is limited...
There are new APIs proposed in [95228](https://github.com/rust-lang/rust/issues/95228) which may eventually lead to the deprecation of `ptr as usize` casts. qcell uses these casts in many places, namely in functions `->...
We don't suppose it'd be possible to have something along these lines? ```rust struct IntrusiveQCellOwner { inner: Arc, } // impl !Clone for IntrusiveQCellOwner; impl IntrusiveQCellOwner { fn new(value: T)...
If someone wants to do their own key management (e.g. `u64` key, panic on exhaustion instead of free list, etc), then have some types that they can plug their own...
It should be possible to support large parts of the functionality in a no_std environment. So add a default "std" feature, and allow the crate user to disable it if...
`TLCell` already supports a kind of transfer of ownership, but only between threads, due to there being an owner in each thread. A `QCell`-like cell could potentially support transferring ownership...
Some possible additions to the API (contributed by pythonesque): > I also proved that the translations `Lcell -> T`, `&LCell -> &[LCell]`, and `&mut T &mut LCell`, are sound for...
would it be possible to have a cell type which is similar to `LCell`, but is based around the `selfref` crate? (maybe with `generativity`? we're not familiar with that crate)...
I believe qcell can support TCell without either of those features enabled, via refactoring the TCellOwner into an unsafe trait with most of the behaviour plus the current struct implementing...
