Semantic of smart pointers

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.

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.

It’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.

While 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.