Pre-RFC (?): unions, drop types and `ManuallyDrop`

[arielb1]

So the idea here is that ManuallyDrop can’t be matched on because its field is private, so therefore the edge cases can’t be reached? I hope that no-one wants to match through a MaybeUninitialized.

[m4b]

Weird, I’ve never heard of unions having any sort of auto-drop behavior (for their contents, I mean; I thought “dropping” a union was basically a no-op).

Sorry I think we’ve been miscommunicating, and its probably my fault. So my union implements drop, which gets “auto-dropped” similar to other rust owned values. I manually tag my unions values using essentially the same method that OCaml does (it reserves a bit in the number to mark whether its a regular number or a block).

I was worried from this proposal that union’s themselves wouldn’t be able to implement drop (which I believe they will still be able to?), but I see this only applies to union’s fields which implement drop, iiuc.

If i’m understanding correctly now, I will still be able to implement Drop for my union, but for my Block, I’ll be forced to add ManualDrop ?

[Ixrec]

Ah, you’re right, that was a total miscommunication. IIUC, none of these posts are saying anything about the ability to manually impl Drop for MyUnionType, so you just have to add ManuallyDrop<...> in the type and a .0 in the Drop impl.

[m4b]

yup, got it now, for my unions drop impl, i’d just do ::std::mem::drop(self.block.0), and update all self.block -> self.block.0 in the union whenever it accesses.

I can also avoid all of this for now if i want, I believe, by removing my drop impl of the block, which is also fine for me.

yea i’m ok with this (as long as ManuallyDrop has repr transparent, because i need to use this union through FFI boundaries)

[RalfJung]

@m4b Yes, the intention was that union fields cannot have automatic drop (to side-step all the questions that immediately opens), but unions themselves can still manually have drop implemented for them like all other nominal types. I will clarify that in the original post.

I suppose a union implementing Drop should have restrictions similar to struct concerning moving out of fields and partial initialization?

So the idea here is that ManuallyDrop can’t be matched on because its field is private, so therefore the edge cases can’t be reached? I hope that no-one wants to match through a MaybeUninitialized .

Which edge cases are you referring to? TBH I did not think about match at all.

[RalfJung]

I just realized that implementing Drop for unions is still unstable. Good . That allows is to figure out those rules, I guess…

[nikomatsakis]

So weaken the current check on stable (fields must be non- Copy ) to test if the type is non- Drop if possible and only fall back to testing non- Copy for type parameters.

I like the proposal overall. I would sort of like to have a better trait than Copy to represent “no-op on drop”, though. I suppose we could add something, let’s cal it NoopDrop, and then have trait Copy: Clone + NoopDrop…?

It raises some interesting questions though about whether it is “opt-in” etc. For backwards compatibility I guess it would have to not be.

Anyway, it just feels a bit weird to have this test, which crops up in various places, but is not truly reflected in the type system in a natural way.

[CAD97]

I can’t quote the exact terminology we’ve been using, but GC would benefit from a "trivial Drop" bound as well. The two ways we have to reason about trivial Drop right now is 'static lifetime or Copy data. The GC experiments so far tend to use 'static.

[nikomatsakis]

I’m not sure – what is the connection between 'static and “trivial drop”? (I took trivial to mean “no-op”)

[Amanieu]

@nikomatsakis A GC will defer dropping an object until an arbitrary point in the future. For this to be safe, either the object must have no destructor, or the object must be 'static and therefore its destructor will only access owned and global data.

[nikomatsakis]

OK, I see. Still, 'static doesn’t seem to suffice to prevent that sort of problem completely. For example, if I have a Gc<Foo> and Foo has a Vec<Gc<Foo>>, I can build up a cycle for which there is no valid order in which to free…? Anyway, off topic.

[TechnoMancer]

So weaken the current check on stable (fields must be non- Copy ) to test if the type is non- Drop if possible and only fall back to testing non- Copy for type parameters.

Isn’t the requirement that the type has no drop glue rather than that it is non-Drop? Any type that contains a type that implements Drop will need drop glue to be run but is not itself Drop.

In this case the magical ManuallyDrop<T> struct will have a lang-item on it that instructs the compiler to never produce drop glue for it no matter what T is?

[RalfJung]

Isn’t the requirement that the type has no drop glue rather than that it is non- Drop ? Any type that contains a type that implements Drop will need drop glue to be run but is not itself Drop .

Yes, that’s what I mean. But you are right that types can be Drop without doing impl Drop for T, so my terminology was not chosen very well.

In this case the magical ManuallyDrop<T> struct will have a lang-item on it that instructs the compiler to never produce drop glue for it no matter what T is?

Yes, that’s exactly the point of ManuallyDrop (which already exists, I just propose to change its implementation).

[rkruppe]

Yes, that’s what I mean. But you are right that types can be Drop without doing impl Drop for T , so my terminology was not chosen very well.

This is very pedantic, but unfortunately the language semantics are confusing enough that we should try to be maximally precise with our terminology. When we say "type is SomeTrait", that is generally colloquial for “the bound TheType: SomeTrait holds”, but for types that have drop glue but no explicit implementation of Drop, that bound doesn’t hold, so it’s misleading to say e.g. "(String,) is Drop".

[RalfJung]

This is very pedantic, but unfortunately the language semantics are confusing enough that we should try to be maximally precise with our terminology. When we say "type is SomeTrait ", that is generally colloquial for “the bound TheType: SomeTrait holds”, but for types that have drop glue but no explicit implementation of Drop , that bound doesn’t hold, so it’s misleading to say e.g. " (String,) is Drop ".

I agree. Terminology is important.

I will edit the first post to speak about (not) having drop glue instead.

[scottmcm]

We now have needs_drop, so maybe there’s a phrasing something like that that could be used.

[RalfJung]

We’d kind of need the inverse of needs_drop as a trait bound.

[hyeonu]

I think the code @m4b wants to write is something like below:

match my_union.some_drop {
    Some(WithDrop(..)) => { .. }
    ..
}

IMO, defining ManuallyDrop as pub struct ManuallyDrop<T>(pub T); should be enough for this case.

[RalfJung]

@hyeonu

You mean this?

match my_union.some_drop {
    Some(ManuallyDrop(..)) => { .. }
    ..
}

Given that accessing the field of a ManuallyDrop is safe and that it implements Deref and DerefMut, I suppose we could allow this.

[drXor]

We’d kind of need the inverse of needs_drop as a trait bound.

Would this work?

// core::mem
pub unsafe auto trait TrivialDrop {}
impl<D: Drop> !TrivialDrop for D {}