@Lokathor do you have any examples in mind ?
I am very against this because it would greatly complicate the unsafe code writing experience for users of the language.
What gets complicated by the proposal in ucg#224 ?
For slice references, we only support
[T]::from_raw_parts, and currently do not support neither type punning through unions, nor the usage of
The only complication I can think of is that
(ptr, len) != [T]::into_raw([T]::from_raw(ptr, len))
but I don't really know how it can show up, since if you have a ZST, all pointers to it will be
align_of::<ZST>() already, and all pointer arithmetic on those does nothing (e.g.
zst_ptr.add(N) == zst_ptr)
I'm not sure if it is even possible to allocate a ZST in Rust at a different address, e.g.,
Box<ZST>::new() will return
GlobalAlloc cannot be used to allocate ZSTs.
One can definitely call a C function that returns a pointer to a ZST at a different address, or materialize one such pointer from an usize (e.g.
42_usize as *const ZST).
You can use
&Box::new((42u8, ()).1 to get a different address, but I don't believe there is a guarantee for this.
not for that type, but for something like
#[repr(C)) struct S(u8, ()) we have such a guarantee I think
since we do specify how the offsets are computed
i replied on the github issue, i didn't want to split the discussion into two places