Pre-RFC: unsafe enums. Now including a poll!

[huon]

@nikomatsakis

Drop otoh is trickier. However, it seems to me it is ok for some of the data in the unsafe enum to be Drop if you define your own Drop impl. But we really want that impl to be the one in charge of dropping the contents. Presumably we handle this by saying that the compiler never drops the contents of an unsafe enum, and (probably) if the contents are not Copy then you must implement Drop.

Hm, I suspect this isn't good enough: I imagine there are often times when there isn't enough information in the enum value itself to work out how to drop it, i.e. the discriminant is stored externally. This will be for cases when an unsafe enum is used for precise pure-Rust data layout control, rather than FFI.

We may just want to just lint or even do nothing about this sort of thing rather than disallow it at a language level (skipping destructors isn't unsafe after all).

@nikomatsakis

Now obviously there is overlap (as has been pointed out numerous times) with the ManuallyDrop proposal. I've forgotten now -- are unsafe enums strictly more general? Are there cases they don't handle? @huon?

There is some subtleties around data representation that may not be desirable for unsafe enums to handle, e.g. if you have unsafe enum Foo { X(&'static u8) } or even unsafe enum Foo { X(&'static u8), Y(Box<u8>) }, can the compiler do the NPO for Option<Foo>?