### Author:  [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)
#### Post date: [November 6, 2015, 11:44am UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/10 "2015-11-06T11:44:14Z")
> [@huon](#):
>
> An Option explicitly wrapping a pointer is a special case in my mind, I specifically don't think Option\ will (well, should) appear in FFI.
Agreed.
---
### Author:  [@retep998](https://internals.rust-lang.org/u/retep998)
#### Post date: [November 6, 2015, 2:30pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/11 "2015-11-06T14:30:16Z")
Regarding the `Copy` and `!Drop` requirements, I’d be okay with making them lints, but possibly deny by default. If `Drop` was allowed, then it would basically be a form of `ManuallyDrop`.
As for whether to use `#[repr(C)]`, I think you should still have to specify `#[repr(C)]` if you intend to have explicit control over the layout or for FFI purposes, otherwise it would be inconsistent with structs. Maybe have a warning if you don’t put `#[repr(C)]`.
Accessing a variant other than the one you initialized is a tricky question. On one hand I don’t want any sort of guarantee that you can do that, since it would prevent things like not initializing unused space in a variant for performance reasons. On the other hand people might have valid use cases for it, just like people have valid use cases for `transmute`. Perhaps define it as having the same defined/undefined behavior as `transmute`? Although with a bit of an extension since this would allow converting between different sized types.
---
### Author:  [@Ericson2314](https://internals.rust-lang.org/u/Ericson2314)
#### Post date: [November 6, 2015, 2:34pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/12 "2015-11-06T14:34:49Z")
Sorry of this is off topic, But has anyone thought about FFI for the case for “discriminated unions” like:
```rust
typedef struct {
uint8_t tag;
union {
bar_t bar;
baz_t baz;
};
} foo_t;
```
---
### Author:  [@retep998](https://internals.rust-lang.org/u/retep998)
#### Post date: [November 6, 2015, 2:45pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/13 "2015-11-06T14:45:54Z")
```rust
#[repr(C)]
unsafe enum foo_t_union {
bar(bar_t),
baz(baz_t),
}
#[repr(C)]
struct foo_t {
pub tag: uint8_t,
pub u: foo_t_union,
}
```
It is a bit more verbose unfortunately.
---
### Author:  [@Ericson2314](https://internals.rust-lang.org/u/Ericson2314)
#### Post date: [November 6, 2015, 6:11pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/14 "2015-11-06T18:11:29Z")
@retep998 Well that represents the foreign type correctly, but I want to have pattern matching an other nice things—trust the C code that it is using its tag correctly.
I was thinking something like
```rust
#[repr(CManual(u8))]
enum Foo {
bar(Bar) = 1,
baz(Baz) = 2,
}
```
---
### Author:  [@retep998](https://internals.rust-lang.org/u/retep998)
#### Post date: [November 6, 2015, 6:19pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/15 "2015-11-06T18:19:20Z")
@Ericson2314 There are a lot of structs out in the C world that have a bunch of fields, a tag somewhere in there, and a union, or maybe even multiple unions, or even nested unions. Supporting all those cases with all your sugar would be massively complicated. While it would be nice to have sugar like that, and maybe one day we can have such sugar, at the moment I just want to get something that lets this be done at all in a flexible manner, without manually calculating alignment + size and calling transmute all the time.
---
### Author:  [@Ericson2314](https://internals.rust-lang.org/u/Ericson2314)
#### Post date: [November 6, 2015, 6:25pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/16 "2015-11-06T18:25:39Z")
That’s fair. Having enums desugar to unsafe unions + structs + magic safety assertions could be a good way to bridge the gap. Last I heard the MIR’s desguaring of match into switch would somewhat dovetail with that.
---
### Author:  [@aturon](https://internals.rust-lang.org/u/aturon)
#### Post date: [November 6, 2015, 6:25pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/17 "2015-11-06T18:25:40Z")
One quick point about sugar for pattern matching and so on: as @retep998 points out, there are lots of ways you might be encoding a tag, and more generally, there are many cases where you’d like to provide pattern matching for non-traditional enums, separate from C interop.
If we wanted to address these cases, I’d suggest looking into something like Scala’s [unapply](http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html), which provides a very slick way to do custom pattern matching in general.
---
### Author:  [@wthrowe](https://internals.rust-lang.org/u/wthrowe)
#### Post date: [November 6, 2015, 8:09pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/18 "2015-11-06T20:09:37Z")
> [@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.
This seems to me like the worst of both worlds: You've lost any guarantees you had about cleaning up the contents (since the `Drop` impl can be defined as a no-op) and you can't use the type in places that forbid destructors (which would limit the usefulness of a `ManuallyDrop` built on top of this).
---
### Author:  [@kstep](https://internals.rust-lang.org/u/kstep)
#### Post date: [November 23, 2015, 8:55am UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/19 "2015-11-23T08:55:53Z")
Being a Scala developer, I can’t plus enough about `unapply` support for generic pattern matching implementation. I think having something like special lang-item `Match` trait would is really nice:
```rust
#[lang = "pattern_match"]
trait Match {
type Result;
fn unapply(&self) -> Option();
}
struct AStruct {
name: String,
count: usize
}
impl Match for AStruct {
type Result = (&str, usize);
fn unapply(&self) -> Option<(&str, usize)> {
(&*self.name, self.count)
}
}
// later
let s = AStruct { name: "Teddy".into(), count: 127 };
match s {
// calls AStruct::unapply(&s)
AStruct { name, count } => {
// types:
// name: &str, count: usize
}
}
```
Upd. This would be even more useful to allow pattern matching opaque structs with private fields, provided by some third-party libs.
---
### Author:  [@repax](https://internals.rust-lang.org/u/repax)
#### Post date: [November 24, 2015, 7:37pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/20 "2015-11-24T19:37:53Z")
If you want to be able to `Drop` an `unsafe enum` you should probably encapsule it in a `struct` (that provides a “safe” interface).
I wouldn’t want to encourage the use of `unsafe enum`s for other things than low-level stuff.
[Next page](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873.md?page=2)