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
OwningHandle currently passes a *const O::Target to the closure passed to new. Because of this, it is not possible to create handles whose inner object depends on a mutable reference to its ancestor object. For a more concrete example, consider:
Now, obviously, this couldn't be fixed just by giving the closure a *mut O::Target, since we'd then potentially run into trouble given that the handle still implements Deref, whereas the inner object may continue to depend on having exclusive access to the outer object. It's almost as though we want this kind of mutable owning handle to only implement DerefMut, though I don't know if there is even a way of doing that?
The concrete use-case I have that needs this (I think) is as follows: I have a thread that at some point receives a factory-like object on a channel in its main loop. When it does, it needs to use that factory to create a new thing from that factory, which it will then use in later invocations. Crucially, the factory is a "one-at-a-time" factory, so it has a signature of fn make<'a>(&'a mut self) -> Useful<'a>, so I can't use OwningHandle in its current form. However, the thread does own the factory, so it should be possible to construct an owning mutable handle in the manner described above.
Another use-case that might fit well with this is RefCell and RefMut. You could construct an owning mutable handle that holds a RefCelland its derived RefMut.
Is this something that might be considered as an addition to owning-ref?
The text was updated successfully, but these errors were encountered:
I just merged #17, which enables the usecase for giving mutable access to the internal mutability handles like RefCell.
I'd certainly consider further additions in this regard! The API grew enough with the last few merges that I think a whole refactor of the crate is in order anyway.
I noticed that the new code uses StableAddress for both immutable and mutable owned references. I was wondering whether it would make sense to use separate traits, since you might have a type where Deref is stable but DerefMut is not.
As a concrete example, my easy_strings library uses copy on write internally, so EZString is stable under deref(), but calling deref_mut() will reallocate the internal buffer.
I think rather than supporting that usecase natively by introducing more traits, it might be simpler to define a Deref-only implementing wrapper type for EZString that implements StableAddress
OwningHandle
currently passes a*const O::Target
to the closure passed tonew
. Because of this, it is not possible to create handles whose inner object depends on a mutable reference to its ancestor object. For a more concrete example, consider:Now, obviously, this couldn't be fixed just by giving the closure a
*mut O::Target
, since we'd then potentially run into trouble given that the handle still implementsDeref
, whereas the inner object may continue to depend on having exclusive access to the outer object. It's almost as though we want this kind of mutable owning handle to only implementDerefMut
, though I don't know if there is even a way of doing that?The concrete use-case I have that needs this (I think) is as follows: I have a thread that at some point receives a factory-like object on a channel in its main loop. When it does, it needs to use that factory to create a new thing from that factory, which it will then use in later invocations. Crucially, the factory is a "one-at-a-time" factory, so it has a signature of
fn make<'a>(&'a mut self) -> Useful<'a>
, so I can't useOwningHandle
in its current form. However, the thread does own the factory, so it should be possible to construct an owning mutable handle in the manner described above.Another use-case that might fit well with this is
RefCell
andRefMut
. You could construct an owning mutable handle that holds aRefCell
and its derivedRefMut
.Is this something that might be considered as an addition to owning-ref?
The text was updated successfully, but these errors were encountered: