Consider supporting stable_deref_trait / working with stable_deref_trait maintainers

[shepmaster]

This would allow Guard (and other types?) to be used with crates like rental.

See also:

• https://github.com/Storyyeller/stable_deref_trait/issues/12

[vorner]

Thanks, I'll have a look at it in a week or so.

[vorner]

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?

[shepmaster]

the Guard will 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 Arc itself is StableDeref and 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!

[vorner]

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