Consider supporting stable_deref_trait / working with stable_deref_trait maintainers
shepmaster opened this issue · comments
This would allow Guard (and other types?) to be used with crates like rental.
See also:
Thanks, I'll have a look at it in a week or so.
Please check my reasoning, but I believe Guard does not satisfy the requirements of the StableDeref.
For example, if I have ArcSwap<String>, the Guard will deref to &Arc<String>. Furthermore, the Arc is kept (wrapped) inside the Guard. This'll violate at least the property of move preserving the returned address.
Nevertheless, the Arc itself is StableDeref and I believe this should be enough for most use cases? You can either extract the Arc (with Guard::into_inner) or maybe even use the property of the eg. String not moving.
Does that make sense to you? Or do I get something wrong in how the StableDeref should work?
the
Guardwill deref to&Arc<String>
Ah, I didn't spend enough time looking at the docs. I assumed it would deref to &String and thus be stable.
the
Arcitself isStableDerefand I believe this should be enough for most use cases
I switched to load_full to get an Arc; is there any substantial difference between the two paths?
do I get something wrong in how the StableDeref should work?
You reasoning makes sense to me! Thanks for taking your time!
Ah, I didn't spend enough time looking at the docs. I assumed it would deref to &String and thus be stable.
It was the case in previous versions, but it turns out this way (deref to Arc) there are some nice advantages ‒ both because I can now deref to Option<Arc<T>> for the ArcSwapOption and because one can manipulate the Arc too (clone, for example).
I switched to load_full to get an Arc; is there any substantial difference between the two paths?
No, it's exactly what load_full does internally :-) https://docs.rs/arc-swap/0.4.5/src/arc_swap/lib.rs.html#761-763