Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translations of T #8

Open
uazu opened this issue Dec 18, 2019 · 4 comments
Open

Translations of T #8

uazu opened this issue Dec 18, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@uazu
Copy link
Owner

uazu commented Dec 18, 2019

Some possible additions to the API (contributed by pythonesque):

I also proved that the translations Lcell<T> -> T, &LCell<[T]> -> &[LCell<T>], and &mut T <-> &mut LCell<T>, are sound for all T, which I don't think your code has yet.

@uazu uazu added the enhancement New feature or request label Dec 18, 2019
@pitdicker
Copy link

I don't think &LCell<[T]>&[LCell<T>] is sound. LCellOwner::rw2 would then allow you to take a mutable reference of both the entire slice LCell<[T]> and the slice element LCell<T>.

Btw. I wrote a post that compares interior mutability types, and some possible extensions that also mentions your crate.

@uazu
Copy link
Owner Author

uazu commented Jan 1, 2020

Thanks. I think @pythonesque didn't include rw2 in his analysis, because he had doubts about it. GhostCell doesn't have rw2. I believe rw2 is sound however as things stand (see issue #7). Thanks for the heads up about potential problems if we mix these features.

@pitdicker
Copy link

Sorry, I remember typing a second reply two days ago. I was too soon to call it unsound.

If LCellOwner::rw2 not only checks the pointers are not equal, but also that the pointers don't fall within the memory of another type (pointer of size_of::<T>()), it is sound.

@uazu
Copy link
Owner Author

uazu commented Jan 3, 2020

Right now all the three types of cells work the same. However only QCell needs to be referred to exclusively by the cell starting address, due to the cell-ID. So yes perhaps the other types could diverge and allow these kinds of operations (with the overlap test you mentioned). I prefer to implement stuff when I have a clear use-case in front of me, so I'm not going to implement this myself for now. If someone shows how this would help them in their project, then I'll look at implementing it, or else support them in making the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants