Union initialization and Drop

[RalfJung]

This RFC realizes the second part of https://internals.rust-lang.org/t/pre-rfc-unions-drop-types-and-manuallydrop/8025: Changing unions to no longer allow fields with drop glue, and otherwise describing what we need to settle before unions can be fully stabilized. Unfortunately this got somewhat more complicated than I thought.

As usual I had trouble separating things between the guide-level and the reference-level explanation; I hope this makes sense!

Rendered
Tracking issue

[petrochenkov]

let _ is a bit of a footgun in terms of testing initialization.
_ pattern doesn't access the right side at all, so even something like this

    let x: u8;
    let _ = x;

successfully compiles.
You need let _y = x; or just x; to test for x being initialized.

[RalfJung]

oops thanks!

EDIT: And fixed.

[joshtriplett]

This doesn't type-check; f2 has type (S, S).

[RalfJung]

Thanks, I also aligned the unions in the two examples.

[petrochenkov]

Nit: "drop glue" is such a rustc-specific jargon, perhaps "trivial destructor drop", or "drop not running any code", or something like this could be better.

[eddyb]

I think "(doesn't) need(s) drop" or "noop drop" could also work as terms.

[RalfJung]

Don't we have a term for "the code that runs when something is dropped"? I feel that is not such a strange rustc-specific concept, all Rust implementations and also e.g. C++ have it.

Personally, I find "noop drop" much less clear than "does not have drop glue".^^

[petrochenkov]

The lint was inherited from the original RFC rather than proposed by me :)

[RalfJung]

Ah, sorry. Fixed :)

[petrochenkov]

Independent nested fields borrowed independently is probably the most natural expectation:

union U { a: (u8, u8), b: u16 }

let x = &u.a.0;
let y = &u.a.1;

so it's borrow checker that needs to work in per-field fashion first of all.
Move checker just mirrors what borrow checker does (for consistency and also because they share common infrastructure in the compiler).

[RalfJung]

Ah, I hadn't thought about borrowck here. So with the rules as stated, once a field is (partially) borrowed, its siblings all become completely blocked from borrowing?

Borrowing is unsafe, so this would not be necessary, but it still seems useful.

[petrochenkov]

LGTM.
It would be nice to see some practical code ported from Drop fields to ManuallyDrop though to estimate impact on ergonomics and readability.

This RFC doesn't seem to prevent reintroducing Drop fields in uncertain future if the need arises, so we don't lose anything by adopting it.

[dlight]

The RFC summary should probably link to something that explains what a drop glue is.

(The Drop chapter of the Rust book doesn't contain the word "glue")

[RalfJung]

It would be nice to see some practical code ported from Drop fields to ManuallyDrop though to estimate impact on ergonomics and readability.

What would be a good example?

This RFC doesn't seem to prevent reintroducing Drop fields in uncertain future if the need arises, so we don't lose anything by adopting it.

Yes. (I avoided calling them "Drop fields" because a field can need drop glue even if it does not impl Drop -- e.g. if it is a struct and one of its fields has impl Drop.)

The RFC summary should probably link to something that explains what a drop glue is.

I added a brief explanation.

[joshtriplett]

@rfcbot merge

Based on discussion in the lang team and with Ralf, I think this is ready to merge. Fields in unions that impl Drop have never been part of stable Rust, so this isn't a breaking change, and this fixes various concerns and painful corner cases that kept coming up.

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

Concerns:

• pnkfelix-wants-a-chance-to-read-this-before-he-checks-his-box resolved by #2514 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[cramertj]

This looks like moving out of a union that implements Drop-- how is this different from the let v = u.f1; case above?

[RalfJung]

You are right, I will fix the example.

The only way to deinitialize a union with drop is to move away the entire thing, just like with structs.

[cramertj]

Why ban just auto-deref rather than banning DerefMut entirely? Users could access the nested types using .as_ptr() or .as_mut_ptr() methods.

[RalfJung]

I felt that was too drastic, but sure.
Probably calling deref_mut manually is also still okay, just the sugar that lets you use * is not?

I also do not know what in technically feasible in this space.

[cramertj]

Yeah, I'm not sure what the right balance is. You want to allow the deref when the value has been initialized, but ban it as much as possible in cases where it creates an &mut T to a partially or wholly uninitialized T.

[RalfJung]

Uh, I think I'd rather avoid such stateful lints. They are not complete enough IMHO (they cannot know which field you are now allowed to create a reference to).

[pnkfelix]

@rfcbot concern pnkfelix-wants-a-chance-to-read-this-before-he-checks-his-box

I've been swamped, but this is an area I sort of care about and I want to read this

[pnkfelix]

@rfcbot resolve pnkfelix-wants-a-chance-to-read-this-before-he-checks-his-box

read it, looks good.

[rfcbot]

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

[daboross]

Should this mention RefCell<T>?

[RalfJung]

Why that? I didn't intend to list every type with interior mutability.

[daboross]

Specifically because the line below is f1: RefCell<T>. I assumed this comment was here to explain why, given that line, this struct is rejected.

[RalfJung]

Oh, I made a typo and didn't use the same type on both sides. Thanks for pointing that out! (GitHub's diff viw for comments embedded in the discussions is so bad...)

[daboross]

No problem - sorry I didn't point it out better initially! I'm still not entirely used to how github displays these things either.

[crlf0710]

Sorry it's a bit late, but in prior art section: Just want to point out that actually C++ does have destructors for unions. (See https://en.cppreference.com/w/cpp/language/union). Maybe a small edit to the text will be good.

[RalfJung]

@crlf0710 Thanks for pointing that out! I fixed the text. Do you agree it is correct now?

[crlf0710]

@RalfJung Looks good!

[SimonSapin]

Would this auto trait be an accurate expression of the “has no drop glue” concept?

pub auto trait NoDropGlue {}
impl<T> !NoDropGlue for T where T: Drop {}

If it is and we make it a lang item (in core::marker), generic unions could be extended to allow fields that are not necessarily Copy:

union Foo<T: NoDropGlue> {
    f: T,
}

[RalfJung]

I think it would begin to express that concept if it worked, but AFAIK those kind of negative bounds don't work...at least I recall that was the result of someone checking last time.

We'd however also need

impl<T> NoDropGlue for ManuallyDrop<T>

and then what about unions themselves? Do they get auto traits the same way everything else does, or are auto traits just never implemented for them? Either way we'd want NoDropGlue implemented for all unions

[SimonSapin]

Good points. So leaving aside the auto-trait definition and assuming it can be implemented with ~compiler magic~ instead, would it be desirable for this trait to exist to enable such generic unions?

[RalfJung]

I would think so, yes. Copy has always been a bad approximation. IIRC either @eddyb or @nikomatsakis had other uses for such a trait as well.

However, introducing such a trait is firmly out of scope for this PR.

[crlf0710]

i think the “has no drop glue” approximately corresponds to std::mem::needs_drop which is implemented using a intrinsic. As the documentation says it's conservative, so... maybe it will be a matter of making it accurate and const fn... Maybe it's also a good idea to lift it to a trait(that's a common problem for all const fns, i think).

[rfcbot]

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

[Centril]

Huzzah! This RFC has been merged!

Tracking issue: rust-lang/rust#55149