search

uazu / qcell

Statically-checked alternatives to RefCell and RwLock
Apache License 2.0
356 stars 22 forks source link

Intereseted in adding a `generativity` based `LCell`? #31

Closed CeleritasCelery closed 2 years ago

CeleritasCelery commented 2 years ago

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.

uazu commented 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.

CeleritasCelery commented 2 years ago

it's just a matter of replacing LCellOwner::scope with LCellOwner::new, which takes a Guard. It could be behind a feature flag.

uazu commented 2 years ago

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.