{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifwrrfdewkcgalbt5uipzhlkmlcmzkmcqhmstpg32osoivf6qcwxu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mnqigyvt55v2"
  },
  "path": "/t/for-structs-that-have-fields-that-have-only-one-possible-representation-enums-should-use-that-field-as-the-discriminant/24382#post_4",
  "publishedAt": "2026-06-08T00:18:19.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I think you have misunderstood the example. Given the `repr(C)` and `repr(u8)` layout rules, the struct `Foo` is guaranteed to have `0x01` stored at offset `3`, and the struct `Bar` is guaranteed to have `0x02` stored at offset `3`. Any value which does not meet one of these conditions is not a valid value of `Foo` or `Bar`. Thus, neither an `&mut Foo` nor an `&mut FooDiscriminant` may be used to write any byte other than a `0x01` at offset `3`, so the enum `FooBar` _could_ use that byte as its discriminant.\n\nThis is a _possible_ layout optimization, but the compiler does not currently support it. It is similar to the case of wanting to collapse two non-overlapping enums:\n\n\n    #[repr(u8)]\n    #[derive(Clone, Copy)]\n    enum Foo {\n        F1 = 1,\n        F2 = 2,\n    }\n\n    #[repr(u8)]\n    #[derive(Clone, Copy)]\n    enum Bar {\n        B3 = 3,\n        B4 = 4,\n    }\n\n    enum FooBar {\n        Foo(Foo),\n        Bar(Bar),\n    }\n\n\nThis could be stored as one byte, but is not (yet).",
  "title": "For structs that have fields that have only one possible representation, enums should use that field as the discriminant"
}