Add map-like methods to AtomicRef(Mut) which work with new objects rather than references

[bholley]

Add map-like methods to AtomicRef(Mut) which work with new objects rather than references

[LechintanTudor]

I successfully implemented all the functionality described above. Please let me know if you are interested in a PR.

[bholley]

Thanks, and sorry for the lag. So the basic issue here is that you want to use a tuple of borrows, but the tuple is technically not a borrowed type, right?

My intuition is that the duplication across {,Owned}AtomicRef{,Mut} would make the code more complex. So unless we find an elegant way to generalize across the permutations, I'm hesitant to take such a patch absent strong demand from multiple consumers. However, I'll leave this issue open so that others can comment if they run into the same issue.

[LechintanTudor]

So the basic issue here is that you want to use a tuple of borrows, but the tuple is technically not a borrowed type, right?

Yes that's exactly it.

[zicklag]

I have a similar need.

I have a type such as AtomicRef<UntypedStorage>, and there's a method to convert a borrow of &'a UntypedStorage to a TypedStorage<'a, T>, but I couldn't do that in AtomicRef.map because TypedStorage is actually an owned type, with the same lifetime as the &UntypedStorage reference, not a reference to a field of UntypedStorage.

[zicklag]

For anybody else who needs it, I was able to accomplish what I needed using the atomicell crate. It has an unsafe method RefMut::into_split() that allows you to get access to the borrow guard and the reference separately, at which point, you must ensure that the reference is never accessed after the borrow guard is dropped, but you can create your own MappedRefMut or whatever you need for your use-case using the guard and the reference.

[Imberflur]

at which point, you must ensure that the reference is never accessed after the borrow guard is dropped, but you can create your own MappedRefMut or whatever you need for your use-case using the guard and the reference.

Note that there is some subtle behavior that you need to be aware of to do this soundly. References passed as function parameters (either directly or included in a type) are treated as if they could be used up until the end of that function even if they aren't used after a certain point (or to put it another way they are expected to not be aliased incorrectly for the entirety of the function).

For an example of how this manifests see #18

To disable this you can wrap the reference/type containing the reference in MaybeDangling from https://docs.rs/maybe-dangling.

For details on why this exists: https://perso.crans.org/vanille/treebor/protectors.html.

[zicklag]

Big thanks for pointing that out to me! That's a very easy foot-gun to miss. I'll look into a PR for atomicell.