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

**URL:** <https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873>\
**Category:** language design\
**Created:** [November 5, 2015, 6:51pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873 "2015-11-05T18:51:18Z")\
**Posts on this page:** 1\
**Showing post:** 55

<div class="post-metadata">

**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\
**Post date:** [December 31, 2015, 3:02pm UTC](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873/55 "2015-12-31T15:02:01Z")

</div>

> if a #[repr(union)] struct has two "fields" with the same type but different names, they still refer to the same thing -- it fundamentally doesn't make sense to have names

I can certainly imagine cases where the type provides sufficient information, but in many of the interfaces I've worked with, names for fields make the code more clear. I'd rather identify a field of a union as "bytes\_remaining" than as "u64". And if a second field "records\_remaining" exists that happens to also have type "u64", I'd rather use the different names associated with different semantic meanings, even if the types happen to coincide.

That said, just as both structs and tuple structs exist, perhaps it might make sense to also support a kind of union with unnamed fields accessed by type. But I don't think that should be the only form of union available.

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-unsafe-enums-now-including-a-poll/2873)._