Tracking issue for #![feature(maybe_uninit_extra,const_maybe_uninit_write)]

[Centril]

This is a tracking issue for the RFC "Deprecate uninitialized in favor of a new MaybeUninit type" (rust-lang/rfcs#1892).

This issue specifically tracks the following unstable methods:

impl<T> MaybeUninit<T> {
    pub unsafe fn assume_init_read(&self) -> T { ... }
    pub unsafe fn assume_init_drop(&mut self) { ... }
}

and it tracks const-ness of

impl<T> MaybeUninit<T> {
    pub const fn write(&mut self, val: T) -> &mut T { ... }
}

[RalfJung]

Latest status here:

I am beginning to think that read should probably be renamed to read_init or read_assume_init or so, something that indicates that this may only be done after initialization is complete.

[SimonSapin]

@RalfJung Should the same logic apply to get_ref and get_mut? #63568

[RalfJung]

That depends on whether references to invalid data are UB or not. If yes, then certainly. If not, then maybe.

Currently they are UB but that's just because it is the more conservative choice.

[ejmahler]

What stands in the way of stabilizing this?

[RalfJung]

Hm, good question. I'd list these:

• Figuring out if the return type of write makes sense and is useful as-is
• Figuring out if these methods are useful enough to justify adding them to the API

[RalfJung]

See #80376 for a potential concern around the return type of write.

@mgeier you mentioned this to be a potential problem for write_slice_cloned; do you think the same issue also applies to write?

[mgeier]

I don't know whether this is an actual problem, but yes, it has the same issue: playground link

BTW, the underlying assume_init_mut() has the same issue: playground link

In the latter case it is arguably worse, because the method name contains assume_init, which suggests to me that this "activates" the destructor, which it doesn't. But I guess that has a different tracking issue: #63568.

For me, the real question is: what are the semantics of assigning to a &mut T?

I assume that when I'm assigning a new value, the old one will be guaranteed to be dropped. But what about the new value? Is the new value guaranteed to be dropped at some point? If yes, this issue is an actual problem.

But AFAICT, it is allowed in safe Rust to call std::mem::forget() on anything, so a &mut T is simply unable to guarantee that an assigned value will ever be dropped.

Still, I'm not sure whether accidental leaking should be made that easy?

[SimonSapin]

We already have stable impl DerefMut for ManuallyDrop which makes this accidental leaking just as easy.

[RalfJung]

In the latter case it is arguably worse, because the method name contains assume_init, which suggests to me that this "activates" the destructor, which it doesn't. But I guess that has a different tracking issue: #63568.

Why do you think assume_init has anything to do with destructors? That was never the intention. The only thing it is intended to convey is "if this is not yet initialized, there's UB".

[mgeier]

Why do you think assume_init has anything to do with destructors? That was never the intention. The only thing it is intended to convey is "if this is not yet initialized, there's UB".

I guess the problem is that the function name assume_init() doesn't contain what it actually does.

Therefore, in my (limited) experience with stable Rust, I've come to imagine that assume_init() is in reality a shortcut that in its full form means "activate the destructor, assuming the memory has been properly initialized before".

That is fine as long as there is only a single function containing the words "assume init".
Now that multiple functions with "assume init" are proposed to be added, this becomes inconsistent and confusing.

I've looked back to the discussions about naming assume_init() (which happened before I was a Rust user) and I found #53491 (comment) which argues "Putting both the emphasis that it has to be initialized and a description of what it does (unwrap/into_inner/etc.) into one name gets rather unwieldy".
I think this was a fine argument as long as there was only one function containing "assume init", but it doesn't work with multiple "assume init" functions.

Now that we have a stable function assume_init(), I think we have to accept that the name assume_init contains more meaning than simply the two words "assume init", and I think we should use the words "assume init" in newly added functions only if they carry the full meaning of the already existing assume_init() function.

[RalfJung]

I am rather surprised by this. Whether or not the destructor runs is fully encoded in the type -- when a T goes out of scope, its destructor runs; when a MaybeUninit<T> goes out of scope, nothing happens. This is the first time that I hear of the idea of "activating a destructor".

Now that we have a stable function assume_init(), I think we have to accept that the name assume_init contains more meaning than simply the two words "assume init", and I think we should use the words "assume init" in newly added functions only if they carry the full meaning of the already existing assume_init() function.

I disagree -- I think having more of these methods will actually make this more clear. Once assume_init_read and assume_init_ref/mut are stable, it seems unlikely that people would associate assume_init with "activating drop".

[Coder-256]

I think in other words, the confusion is that assume_init/assume_init_read move the value, meaning it will be dropped, but assume_init_ref/assume_init_mut only reference the value, meaning it will not be dropped. I see how this can be confusing but honestly I actually like design because it's pretty similar to how pointers already work: the former two are like std::ptr::read(), and the latter two are like casting from a pointer to a reference.

[mgeier]

@RalfJung

This is the first time that I hear of the idea of "activating a destructor".

Sorry that I'm using such naive and hand-wavey terminology.

But that's how I, as a humble Rust user, think about it. I have a MaybeUninit<T> variable which I, let's say initialize with some FFI function. Now the bits in memory have already the correct values, but in order to further work with it, I'd like to turn it into a T, which logically only does one thing: it "activates" the destructor.

I think having more of these methods will actually make this more clear. Once assume_init_read and assume_init_ref/mut are stable, it seems unlikely that people would associate assume_init with "activating drop".

That's true, but also because assume_init() will be stripped of any meaning with regards to what it actually does.

But anyway, I'm wondering: why do we even need assume_init_read and assume_init_ref/mut?

Aren't they just wrappers for one-liners?

I have the feeling that adding all those function will make Rust more complicated without really gaining anything.

I think using the one-liners directly makes it much more obvious to see what actually happens in the code.

@Coder-256

I see how this can be confusing but honestly I actually like design because it's pretty similar to how pointers already work: the former two are likestd::ptr::read(), and the latter two are like casting from a pointer to a reference.

I don't think this is similar at all. The function name std::ptr::read() contains a verb that tells me what the function actually does. In contrast, assume_init() does not tell me what it actually does (but granted, I can get quite a good idea by looking at the involved types).

Casting from a pointer to a reference isn't similar either. It is done by using sigils alone and doesn't involve any function names at all.

[RalfJung]

That's true, but also because assume_init() will be stripped of any meaning with regards to what it actually does.

Well, the main meaning (I'd say) is that initialization is done and the compiler may now assume that the data is initialized. So I don't think meaning is "stripped".

But anyway, this is useful feedback, even if I don't quite know what to do with it. ;) Thanks!

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[ojeda]

AFAICT, no PR was sent for this. Sending one for the maybe_uninit_extra bit.

[SOF3]

Why is it called assume_init_read? Are there similarly named concepts anywhere else (in the stdlib or the community)? This is just looks like a memcpy to me.

[RalfJung]

Yes, there are other assume_init functions on MaybeUninit. They are all just memcpys, but they are type-changing memcpys and that makes all the difference.

[Kixunil]

To me it's a natural combination of ptr::read() and assume_init.

[Finomnis]

What about the stabilization of const_maybe_uninit_write? It seems like the feature leads to this tracking issue, yet it doesn't get discussed here anywhere. Unless I'm missing something.

[RalfJung]

That's blocked on stabilizing any use of &mut in const.

[DaniPopes]

Opened #116233 to const-stabilize assume_init_read since it looks like it was only blocked by ptr::read (#92768 (comment)), which has since been stabilized in 1.71.