Tracking Issue for mem::conjure_zst (feature(mem_conjure_zst))

[scottmcm]

Feature gate: #![feature(mem_conjure_zst)]

This is a tracking issue for the mem::conjure_zst::<T>() function.

There are a variety of possible ways one can do this without this function, but it provides two advantages:

1. It makes it clearer to the reader what's happening and keeps the code author from needing to decide between zeroed() or uninitialized() or MaybeUninit::new_uninit().assume_init() in situations like
   

   rust/library/alloc/src/vec/into_iter.rs

   Lines 149 to 150 in ab0c2e1

   	// Make up a value of this ZST.
   	Some(unsafe { mem::zeroed() })

2. It provides a convenient place to talk about why it's not just safe to do this in all cases.

Public API

// core::mem

pub const unsafe fn conjure_zst<T>() -> T;

Steps / History

• Implementation: Add mem::conjure_zst for creating ZSTs out of nothing #95385
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[clarfonthey]

Posting this here since it doesn't have to be part of the initial PR, but I think there should be a lint for creating uninitialised ZSTs using other methods, since this should be the canonical way to do so.

Another potential thing: if we make it so that calling conjure_zst is a compiler error for non-ZSTs, then what exactly is the unsafe signifying? We can't actually cause any undefined behaviour with it, and although it's currently not possible to do this in safe code, I don't think it's necessarily bad to make it safe, although I do think that it shouldn't be used outside unsafe code. Definitely could break invariants with it.

[scottmcm]

Definitely could break invariants with it.

That's why it has to be unsafe -- see the docs in the PR.

I can write code whose soundness depends on the fact that the only way to get an instance of a particular ZST is by asking me. For example, maybe when you ask for the ZST I initialize some static state. Then even if the ZST is Copy, I can require that you pass me an instance of it and I know that said state is already initialized, without needing to check.

But if you can just conjure that ZST in safe code, that would become unsound.

if we make it so that calling conjure_zst is a compiler error for non-ZSTs

Note that it being an error to even mention for a non-ZST would make it not work in the kinds of places that inspired me to make it. If you look at the PR, the uses are guarded by runtime zero-sizedness checks -- the compiler doesn't know it's a ZST. And it's monomorphized for non-ZSTs, those just happen to be in dead code.