{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif4hyi2mvhpmckaqtq6vgwog3luux6zi5pfk2gkakgi7aqcnvsrsa",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mmkn6bvwnnl2"
  },
  "path": "/t/pre-rfc-guarantee-that-pointers-to-osstr-has-the-same-layout-as-pointers-to-str-u8/24354#post_1",
  "publishedAt": "2026-05-23T23:35:45.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "vanishingly few guarantees about the layout of pointers to unsized types",
    "pointers to str have the same layout as pointers to [u8]",
    "OsStr",
    "Path"
  ],
  "textContent": "Rust makes vanishingly few guarantees about the layout of pointers to unsized types. To my knowledge, the only exception is that pointers to str have the same layout as pointers to [u8]. I propose extending this guarantee to `OsStr` as well as `Path`. `OsStr`'s three implementations and `Path` all currently support this as a consequence of being `repr(transparent)` newtypes of either `str` or `[u8]`, but there are comments (_not_ doc comments!) above the definitions of OsStr and Path stating that this \"is considered an implementation detail and must not be relied upon\".\n\nThe primary use case for this guarantee is casting/transmutation: it is easy enough to convert between `&str` or `&[u8]` and `OsStr` or `Path`, but the same cannot be said for conversions between `&[&str]` or `&[&[u8]]` and `&[&OsStr]` or `&[&Path]`. Given that `OsStr` and `Path` are by all accounts intended to be newtypes that model strings with constraints somewhere between those of `&str` and `&[u8]`, I think it makes sense to provide layout guarantees in turn.",
  "title": "Pre-RFC: Guarantee that pointers to `OsStr` has the same layout as pointers to `str`/`[u8]`"
}