[dathinab]

It's the correct answer.

You still sometimes need it like:

- when highly optimizing some algorithms

- doing FFI

So places you find it include some aync runtimes, some algorithm libraries, the standard library.

Still often times you initialize it by fully writing it, not by writing fields.

Anyway rules are simple:

1. use `ptr::write` instead of `ptr =`

2. use `addr_of_mut!(ptr.x)` instead of `&ptr.x` to get field pointers

3. uhm, `packed` structs are a mess, if you have some you need to take a lot of additional care, this is not limited to rust but also true for C/C++

Also you do not need `#[repr(C)]`, while the rust-specification is pending and as such `repr(Rust)` is pretty much undefined you still can expect fields to be aligned (as else you would have unaligned-`&` which is quite a problem and would likely cause a bunch of breakage through the eco-system).

[kaba0]

There may of course be rare cases where having it uninitialized helps, but I would wager that even than the compiler could optimize it more often than not.

[dathinab]

It's not that simple.

Like the unused bu allocated space in a Vec is basically a `[MaybeUninit<T>]`.

Or in async runtimes you often have an unsized type with an future trait object inlined (through unsized types anyway need a bit more love ;=) ).

Or some C FFI patterns.

But yes I would say in pure rust the use cases for `MaybeUninit` are rare, and the cases where you need pointers to fields even rarer.

Though while rare in comparison to the amount of code not needing it, still needed enough to be somewhere used (e.g. in a dependency) in many projects even if ignoring std.

[kaba0]

Fair enough, I was thinking more along something like making a struct and then iteratively filling out its fields, maybe even through passing a reference to it to another function. After inlining, it should be “uninitalized” in x86 instructions.