feat: attach_to_cart_mut and try_attach_to_cart_mut

[Ddystopia]

This PR adds attach_to_cart_mut and try_attach_to_cart_mut constructors, to allow passing mutable references into Yokable. It composes well with Yoke::with_mut.

Note that StableDeref requires ¹ multiple calls to deref, and deref_mut if implemented, to return the same address.

Footnotes

1. https://docs.rs/stable_deref_trait/latest/stable_deref_trait/trait.StableDeref.html ↩

[CLAassistant]

All committers have signed the CLA.

[Manishearth]

I can't see any obvious problems with this API but it does make me nervous, especially from the POV of subtler unsafety rules: what is the use case for this API?

We already may go down the route of restricting what is allowed within a cart to solve #2095, which would potentially make the use cases of this API even less workable.

[Ddystopia]

My use case involves the (costly) creation of a view on a buffer, followed by mutations to that data. The with_mut method is already available, allowing unrestricted access to &mut references to the cart. I believe this can be achieved if the Deref implementation returns a type with interior mutability, enabling attach_to_cart to extract &mut. However, this approach introduces runtime overhead or requires unsafe code. I attempted using ghost_cell, but it requires a brand lifetime in yokable, whereas only a single lifetime is permitted.

[Manishearth]

allowing unrestricted access to &mut references to the cart

It allows reasonably restricted access to mutating the cart via the yokeable, which is a bit different. But that is also one of the APIs that is tricky around #2095 when paired with the cart getter.

Interior mutability on the cart is partly where #2095 gets trickier, too.

Generally we're happy to wait on fixing #2095 until the Rust unsafe guidelines around this are fully solid and they have utility APIs that help us; but I'm also wary of adding more APIs that may need to be removed in the future.

---

Could you share the concrete code pattern you hoping to use, vs the code pattern you have to use without this API?

(Also, this API needs an example anyway, if you can generalize the code pattern a bit)