{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidsjmesrzohy6gbu5x4jv23szmwx6srq247n5ltajtxi4mp4c5sqa",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3me75pztlvq22"
  },
  "path": "/t/pre-rfc-place-traits/23950#post_10",
  "publishedAt": "2026-02-06T14:36:21.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Apologies for the delay in responding, it took longer than expected to rework the draft and find time for that. The original post is updated with the new text.\n\nYes, there will indeed be significant restrictions on what the implementations of `Place::place` and `Drop::drop` are allowed to do on types implementing `Place`. As i see it, this is an unavoidable consequence of essentially giving more control over the contents (i.e. the thing pointed to by the pointer returned by `Place::place`) to the compiler. This is why this trait is unsafe, and is one of the drawbacks of this particular approach.\n\nFrom my perspective, it seems almost unavoidable to have such severe unsafe requirements if the goal is to replicate the behavior of Box. There are some alternatives as explored in the alternatives section, however these are unable to fully replicate the specialness of Box. And these special behaviors of Box provide some real potential value (see the future possibilities section). Hence I think this is the better compromise.\n\nOn that note, I am getting quite happy with the text as it stands, so I may make the pull request on the rfcs repo in the next few days unless something drastic turns up. Thank you everyone for all the feedback, it has definitely helped to further improve the text.",
  "title": "Pre-RFC: Place traits"
}