@alexcrichton I know you had an interesting test case for this:

enum Foo { NoDrop, NeedsDrop(Box<int>) }
impl Drop for Foo {
    fn drop(&mut self) {
        *self = NeedsDrop(box 3);
    }
}

but this just overflows the stack, which I guess is intended behaviour?

This program also overflows its stack, so I think it is intended behavior yeah:

struct Foo;

impl Drop for Foo {
    fn drop(&mut self) {
        *self = Foo;
    }
}

fn main() {
    let _a = Foo;
}

I'm not sure if there was a philosophical reason that Drop couldn't be implemented on enums in the first place or whether it was just an unimplemented part of the compiler. If it were the former, then we may want to introduce this behind a feature gate for now (unless you're confident), and if it's the latter then all is well!

@alexcrichton I see! Happy to feature gate it for now. I wasn't sure if this may in fact warrant an RFC.

@alexcrichton IIRC it used to ICE.

Indeed it used to ICE, but was that intentional or accidental? (I don't know)

There's no reason why Drop shouldn't work on enums.

History time!

• Originally drop { ... } was a property of trait objects (back then called obj).
• Then drop { ... } became a property of so-called resource types, which we would today call tuple structs with a Drop impl.
• Then drop { ... } became a property of classes, which evolved into the structs of today.
• Then Drop was made more general and became a trait you could implement on anything nominal. In theory. In practice it was done by retrofitting the old class destructor code to work with the new Drop implementation via a few hacks in coherence. This was never intended to a permanent state of affairs, but the implementation largely survives to today.

Nice @pcwalton

@pcwalton Interesting, thanks!

@pcwalton Would you be able to take a look at this? :-)

Seems OK modulo a couple of nits.