{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidmxqt6uiikmnsnkvydz2bdmse4epq3inz7hbics4vdqwdx5hx4uy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mk7asb27pvf2"
  },
  "path": "/t/could-collections-hypothetically-store-keys-and-values-inline/24195#post_1",
  "publishedAt": "2026-04-23T23:32:53.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "https://github.com/rust-lang/rfcs/pull/3712#issuecomment-3715013712"
  ],
  "textContent": "Speaking only with respect to the default allocator:\n\n`Vec<T>` and `String` document that they never use any sort of \"small optimization\" where some `[T]` or `str` data is stored inline in the main `Vec` or `String` allocation. They also do not have unique/`noalias` semantics like `Box<T>` or `&mut T` do; although this is technically not documented, because people already rely on this property, it would be considered a breaking change to add `noalias` semantics to them: https://github.com/rust-lang/rfcs/pull/3712#issuecomment-3715013712\n\nThese guarantees (and other guarantees of the language) imply that self-referential structs can soundly use `Vec<T>`s or `String`s as backing data for self-references to the associated `[T]` or `str` data; moving a `Vec<T>` or `String` does not invalidate references (whether `&` or `&mut`) to their heap data.\n\nThe data structures in `std::collections`, however, do not explicitly document that they never store values (or, if applicable, keys) inline; AFAICT, this is technically \"just\" an undocumented implementation detail of `std`. Should I start making an RFC requesting this guarantee?\n\nOr is there some reason I'm missing that already prevents `std::collections` data structures from storing values and (if applicable) keys inline, _even_ hypothetically? In other words, can `unsafe` code **stably** and soundly use e.g. a `HashMap` as backing data for self-references to keys and values?",
  "title": "Could collections hypothetically store keys and values inline?"
}