Sure. I would like to hold
Child in the same struct. I can’t rely on
Copy, and I want to hold the actual
Parent object in the
Combined struct, not just a reference (imagine I needed to return the
Combined struct from a function).
Here’s a less contrived example, and one I ran into in a project of mine. The
libusb::Context definitely shouldn’t be
Copy, and the
get_device function was a callback from a C library, so I needed to return all state in one struct (then cast to a void *). I think the
libusb wrapper library is doing everything right: the
Device holds a fake reference to the
Context variable to ensure that the device outlives the libusb context. But this also introduces the restriction that a
Device and associated
Context can’t live in the same struct. In this example, this is an unnecessary restriction because there’s no actual reference.
I’m looking for a way to tell the compiler that one object needs to outlive another, but without using a reference.
PhantomData is a way to get some effects of a struct member but not others (you get type-safety and lifetimes but without allocating memory for that member). I’m looking for a
PhantomRef which would allow me to get some effects of holding a reference (lifetimes) without others (the value-and-reference-in-the-same-struct restriction).
As far as I know this needs to be provided by the compiler (i.e.
PhantomRef can’t be provided by some other crate). I’m wondering if something like this would be easy to implement and if it’s a feature the compiler team would want to expose.