# The Pin unsoundness and \`CoerceUnsized\`

**URL:** <https://internals.rust-lang.org/t/the-pin-unsoundness-and-coerceunsized/11593>\
**Category:** language design\
**Created:** [January 8, 2020, 4:42pm UTC](https://internals.rust-lang.org/t/the-pin-unsoundness-and-coerceunsized/11593 "2020-01-08T16:42:50Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)\
**Post date:** [January 28, 2020, 10:07pm UTC](https://internals.rust-lang.org/t/the-pin-unsoundness-and-coerceunsized/11593/17 "2020-01-28T22:07:49Z")

</div>

> [@withoutboats](#):
>
> I think the main problem here might be with clone: its seems very plausible there exists a combination of Clone on a custom pointer and CoerceUnsized on that pointer that, when combined with the Clone and CoerceUnsized impls on Pin, give you a falsely pinned pointer. But we can't require that Clone return a pointer that points to the same value.

For my argument above to work, we basically have to require that doing the unsizing coercion does not change the `Deref`/`DerefMut`/`Clone` impl that will be called. Because if that changes, there is just no way to show the [proposed `Pin` invariant](https://internals.rust-lang.org/t/unsoundness-in-pin/11311/113) for the newly coerced pointer.

With that constraint, how could `Clone` and `CoerceUnsized` cooperate to cause a problem here?

---

_[View the full topic](https://internals.rust-lang.org/t/the-pin-unsoundness-and-coerceunsized/11593)._