# Semantic of smart pointers

**URL:** <https://internals.rust-lang.org/t/semantic-of-smart-pointers/24345>\
**Category:** libs\
**Created:** [May 19, 2026, 2:33am UTC](https://internals.rust-lang.org/t/semantic-of-smart-pointers/24345 "2026-05-19T02:33:02Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Evian-Zhang](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/evian-zhang/32/12170_2.png) [@Evian-Zhang](https://internals.rust-lang.org/u/Evian-Zhang)\
**Post date:** [May 19, 2026, 2:33am UTC](https://internals.rust-lang.org/t/semantic-of-smart-pointers/24345/1 "2026-05-19T02:33:02Z")

</div>

"Smart pointer" is an individual concept in [The Rust Programming Language](https://doc.rust-lang.org/book/ch15-00-smart-pointers.html) book. However, I didn't find a semantic-level definition of what "smart pointer" is. Should there be some traits in core/std to provide this semantic?

This question arises from another question ([How to constrain types where `AsRef` and `AsMut` point to the same data? - help - The Rust Programming Language Forum](https://users.rust-lang.org/t/how-to-constrain-types-where-asref-and-asmut-point-to-the-same-data/140144)) I posted in the users forum:

> When a function requires a smart pointer over a specific type, how to express this constraint?

I guess this scenario is common? In my code, I often require a smart pointer to `[u8]` buffer, which enables me to access and modify the buffer's data (without appending or removing the buffer). Discussion of the problem: whether the code patterns that require a smart pointer is common, is also very welcome 🙂

I was thinking of an `unsafe` trait (also suggested by others in the users forum post):

```rust
/// # SAFETY
///
/// Implementors should make sure the .as_ref() and .as_mut() returns the same data
unsafe trait AsData<T>: AsRef<T> + AsMut<T> {}

```

However, the correctness requirement in "SAFETY" section is still too weak to describe a smart pointer (which is also pointed out in the users forum post). The requirement only states that `as_ref` and `as_mut` return the same data, but there is no requirement of temporal consistency: the pointed data address should never change unless we deliberately replace it through `as_mut`. This is to prevent the implementors to randomly return different pointers in each invocations. I thought this is something like the [`DerefPure`](https://doc.rust-lang.org/stable/std/ops/trait.DerefPure.html) trait. This requirement is hard to express correctly, since what will happen if the smart pointer is a `Vec` and it reallocates?

So I suggest we shall discuss the semantic of smart pointers in Rust, and is it desirable to add some related trait to the core/std to express the semantic in type system?

---

<div class="post-metadata">

**Author:** ![robofinch](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/robofinch/32/13874_2.png) [@robofinch](https://internals.rust-lang.org/u/robofinch)\
**Post date:** [May 19, 2026, 2:25pm UTC](https://internals.rust-lang.org/t/semantic-of-smart-pointers/24345/2 "2026-05-19T14:25:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Evian-Zhang](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/evian-zhang/32/12170_2.png) [@Evian-Zhang](https://internals.rust-lang.org/u/Evian-Zhang)\
**Post date:** [May 19, 2026, 3:15pm UTC](https://internals.rust-lang.org/t/semantic-of-smart-pointers/24345/3 "2026-05-19T15:15:10Z")

</div>

Thank you for your reply!

> [@robofinch](#):
>
> If it’s for the _soundness_ of `unsafe` code, then I think that needs are commonly fairly specific to the `unsafe` code.

Yes, I care about unsafe code.

> [@robofinch](#):
>
> 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

Yes, and that is exactly why I thought defining a smart pointer is hard. Rc, for another example, cannot implement AsMut.

> [@robofinch](#):
>
> While I’ve been assuming that there’s some reason you can’t just use `&mut [u8]`

Yes, `&mut [u8]` can work.

> [@robofinch](#):
>
> it’d be even better if your code didn’t need to own the buffer.

Then if the struct containing the reference needs to be moved around, it will be very hard for the library user to maintain the code, I guess.