# Unsoundness in \`Pin\`

**URL:** <https://internals.rust-lang.org/t/unsoundness-in-pin/11311>\
**Category:** language design\
**Created:** [November 18, 2019, 12:12am UTC](https://internals.rust-lang.org/t/unsoundness-in-pin/11311 "2019-11-18T00:12:38Z")\
**Posts on this page:** 1\
**Showing post:** 33

<div class="post-metadata">

**Author:** ![withoutboats](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/withoutboats/32/4560_2.png) [@withoutboats](https://internals.rust-lang.org/u/withoutboats)\
**Post date:** [November 20, 2019, 12:36pm UTC](https://internals.rust-lang.org/t/unsoundness-in-pin/11311/33 "2019-11-20T12:36:08Z")

</div>

Okay, I've read the thread. I think `CoerceUnsized` should be left as a blocker on stabilizing that trait and set aside for the moment (edit: but my opinion is along the same lines as the rest of this post - it should be a requirement of coerceunsized, enforced however we see as best, that the target of the deref doesn't change).

I think we should essentially reserve the other two impls unless a crater run shows it would have a really negative impact on some users. While we can add a special work around for `Pin` with a marker trait, my belief is that users should be able to assume that `for<'a, T: ?Sized> &'a T !: DerefMut` et cetera. It's common sense. I would only want to add a pin-specific marker trait if this were not possible.

We should also explore if there are other impls that `#[fundamental]` allows on references that completely defy common sense. Nothing strikes me.

> [@nikomatsakis](#):
>
> I'm not sure that works -- reservation impls were designed to **allow** overlap from downstream crates. They act in somewhat surprising ways, IIRC. See [the tracking issue](https://github.com/rust-lang/rust/issues/64631)

So maybe not reserve through the same mechanism as that but my opinion is we should treat the fact that users can write these impls as the soundness hole (rather than something specific to pin) and find a solution to that.

EDIT2: not sure how the attribute interacts with specialization, but I would _hope_ it would treat this impl as unspecializeable if its a non-marker trait with all non-default items. If not, that change seems appropriate? In which case, I believe it works to just reserve these impls?

---

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