{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie5xfgwhziofqlegjnuxeuleb655fhgfvy2makgyr4ieoydt6ciwq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlgruus5j722"
  },
  "path": "/t/core-path/24233#post_5",
  "publishedAt": "2026-05-09T16:18:52.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "std::panic::PanicInfo"
  ],
  "textContent": "Risks I see in this design:\n\n  * Currently, items in `core` and `std` with the same paths are generally identical. Changing that makes it harder to correctly migrate code to `no_std` compatibility, and also interferes with the possible future where instead of a `core`/`alloc`/`std` split, we have `std` with feature flags. (There is, currently, one exception to this principle already, std::panic::PanicInfo, but that came with providing an alternative and deprecating the existing name.)\n  * Individual operating system variants or versions may have particular quirks of path parsing that `std::path::Path` needs to be aligned with, which may not be as simple to define as having a single `Unix` type and a single `Windows` type. (I don’t know if this there are any examples of this today.) This means that more than two syntax types would have to be introduced, and this might put Rust in the position of either causing a breaking type mismatch, or having security bugs.\n\n",
  "title": "core::path::Path"
}