Legal values for a `&T` or `&mut T` where `T` is zero-sized

In #3, the question was posed what values a Box<T> where T is ZST can have – one might ask a similar question about a &T. The answer may well be the same as #3, but it could be different, depending on whether the Box API is deemed to impose its own limitations.

[arielb1]

I mean the protocol that governs the type while it is shared

This is the memory model repo, not the soundness repo.

[mystor]

I think that any non-null value should be OK, and that the compiler should correctly propagate that value. It is useful and expected in #[repr©] structs for a ZST before a sized type to have the same address of that field.

In addition, ZSTs have the advantage that they can be passed around as &T and &mut T while not allowing the consumer to move the actual data behind the reference (which may be a variable sized #[repr©] struct). The methods on the ZST T can then cast the reference to a reference to the actual backing data type, and avoid unsafety that would come by allowing moving, for example, the header of a FFI C type. I think patterns like that should be OK, as they solve a real problem, and shouldn’t break anything.

This means that pointers to opaque C structs can be passed around like native rust types behind &T and &mut T, rather than requiring special structs like:

struct SomeCTypeRef<'a> {
    ptr: *const SomeCType,
    _marker: PhantomData<&'a u8>,
}

which require a large number of impls on them and don’t provide a nice API.