{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidshbl5hxwqon43vczb6vmf66jpotvwkfmh2yqjw6ggked5ra6jem",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mhydht6aulh2"
  },
  "path": "/t/on-replacing-unsafecell/24113#post_1",
  "publishedAt": "2026-03-26T13:56:02.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Rust Playground",
    "[1]",
    "↩︎"
  ],
  "textContent": "It looks to me like UnsafeCell is not really a type, but rather property of a struct field.\n\nSee: moving it, including passing as a function argument or return value, can replace UnsafeCell with a simpler type:\n\n  * `UnsafeCell<T>` == `T`\n  * `&UnsafeCell<T>` == `NonNull<T>`\n  * `&mut UnsafeCell<T>` == `&mut T`\n\n\n\nAnd it is about \"interior mutability\" where said \"interior\" is often relative to some struct.\n\nTherefore a new language feature could be worked out. Its bikesheddable name is \"lit/twilight field dichotomy\" (`#[feature(twilight_fields)]`).\n\n## A description of new feature\n\nAll ordinary fields of a struct are called _lit_ ; structs are now also allowed to have _twilight_ fields which are internally mutable and potentially uninitialized (could be controlled inside an attribute).\n\n\n    struct Foo {\n        #[twilight] special: String,\n        common: u32,\n    }\n\n\nAccess to a twilight field (`foo.special`) produces a nonnull pointer to the contents (`NonNull<String>`), regardless of whether `foo` was owned, or shared reference, or exclusive reference. Again regardless of the origin, this pointer has at least read-write provenance for the String.\n\nThe twilight fields are stored together with lit ones, and, importantly, moved along the struct (but considered potentially uninitialized). They are accounted in its size and alignment.\n\n`&Foo` and `&mut Foo` do not alias twilight fields (presumably they have no provenance to read or write them, but still allowed to do pointer arithmetic since it's inbounds of a `Foo` allocation).\n\n## Required compiler support\n\nHalf of this feature can be implemented with unsafe code; unergonomic it (Rust Playground) may be, but it passes Miri except for the leaked memory (destructors for twilight fields should be worked out). However such a struct has to be constructed in-place; compiler support would allow having it first-class and moving it as needed.\n\n## What it would solve\n\nThe complications of `UnsafeCell`, `UnsafePinned`, `!Unpin`, `ManuallyDrop<Box<_>>`, and future's ref aliasing[1]; all kinds of accesses could finally be managed in code.\n\n* * *\n\n  1. At a certain cost, though; that `&mut Foo` does no longer provide write access to the whole of its span. ↩︎\n\n\n",
  "title": "On replacing UnsafeCell"
}