Closed CeleritasCelery closed 2 years ago
Okay, that would likely be useful for people using LCell. It would probably be best to add this as a Cargo feature. Is it just a matter of adding a new constructor to LCellOwner? I guess the existing LCell doc-tests would have to be duplicated for generativity.
it's just a matter of replacing LCellOwner::scope
with LCellOwner::new
, which takes a Guard
. It could be behind a feature flag.
What I'm trying to ask is whether this is a simple add-on to the existing LCellOwner type, or whether it has to be a completely different type. It would be a breaking change to remove LCellOwner::scope
. Looking at your fork, Id
is a type from generativity
. Generativity's Id
has a couple of extra terms compared to qcell's, but the author doesn't explain why they are there. According to my reading of the Rustonomicon, they are not necessary, and they restrict UnwindSafe, so I think we should not use their Id
. So the question is whether you can implement this as an addition, i.e. just add LCellOwner::new
that accepts a generativity Guard. If that looks like it would work and be safe, I think this would be fine. I'd prefer it to be behind a feature flag so that people who don't need it don't get an extra dependency to consider in their safety review.
For one of my projects I am using a fork of
LCell
with the generativity crate to avoid the requirement for closures. Is this something you would be interested in having contributed back to this crate? If so I will put together a PR.