{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib5vlmmaiwvbf5mrfj4d4x5ayljqaod3bbde5mwyb5sl7dhzuy4ti",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mm7xsfplfqi2"
  },
  "path": "/t/semantic-of-smart-pointers/24345#post_2",
  "publishedAt": "2026-05-19T14:25:30.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "If it’s just for _correctness_ , then you can just document “hey, if you use pathological `AsRef`/`AsMut` implementations, this code could panic or be incorrect.” If it’s for the _soundness_ of `unsafe` code, then I think that needs are commonly fairly specific to the `unsafe` code. A generic “smart pointer” can just do _so_ many things.\n\n`Cow` is considered to be a smart pointer, for example, and while `std`’s `Cow` _doesn’t_ implement `AsMut`, it doesn’t seem _entirely_ unreasonable that a non-`std` `Cow`-like type could be copy-on-write while implementing both `AsRef` and `AsMut`. I don’t think that would be a _good_ idea unless the copy-on-write can be performed cheaply and infallibly (so, no allocating or locking, which is quite restrictive for copy-on-write), but someone might complain if The Generic Definition of Smart Pointer (TM) doesn’t allow for copy-on-write in its equivalent of `as_mut`/`borrow_mut`/`deref_mut`.\n\nIt’d be better to make or use an `unsafe` trait with exactly what you need. Personally, I need a generic growable buffer more frequently than a generic fixed-size buffer, and abstracting the functionality for growing necessitates a trait anyway.\n\nWhile I’ve been assuming that there’s some reason you can’t just use `&mut [u8]` (or raw pointers), I suppose it’s worth saying at least _once_ that it’d be even better if your code didn’t need to own the buffer.",
  "title": "Semantic of smart pointers"
}