# \`impl\<T: Copy\> Copy for &mut T\`?

**URL:** <https://internals.rust-lang.org/t/impl-t-copy-copy-for-mut-t/414>\
**Category:** ideas (deprecated)\
**Created:** [August 20, 2014, 10:22am UTC](https://internals.rust-lang.org/t/impl-t-copy-copy-for-mut-t/414 "2014-08-20T10:22:38Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![glaebhoerl](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/glaebhoerl/32/1978_2.png) [@glaebhoerl](https://internals.rust-lang.org/u/glaebhoerl)\
**Post date:** [August 20, 2014, 10:22am UTC](https://internals.rust-lang.org/t/impl-t-copy-copy-for-mut-t/414/1 "2014-08-20T10:22:38Z")

</div>

If I write a struct:

```
struct Foo<T> { foo: T }

```

then `Foo<T>` will be `Copy` if and only if `T` is `Copy`.

Right now, `&mut T` is never `Copy`, always affine (move-only). This is because mutable aliasing in general can violate soundness, i.e. the iterator invalidation problem. But you clearly can’t violate soundness with, for example, a mutably aliased `int`.

What I’m wondering is whether we could, or should, do the same thing for `&mut T` as for `Foo<T>`, and say that it’s `Copy` iff `T: Copy`. This would essentially mean allowing things which are `Copy` (“plain old data”) to be mutably aliased. We already do this under controlled circumstances with `Cell`.

Doing this would have obvious benefits in terms of expressiveness. What negative aspects would it have? I don’t _think_ it would compromise soundness (sketch of a proof: otherwise `Cell` would also be unsound). But it would involve losing some guarantees, e.g. right now, if you have an `&mut int`, you can know that nobody else can mutate that `int` but you. This would no longer be true (similar to `&const`).

EDIT: Here’s a more serious problem: it would also break the guarantee for `&int`, because you can borrow `&mut int` to `&int`. So `&int` would also behave like `&const int`. I’m liking this idea less now.

Has this idea been considered before?

cc @nikomatsakis

---

<div class="post-metadata">

**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\
**Post date:** [August 20, 2014, 10:20pm UTC](https://internals.rust-lang.org/t/impl-t-copy-copy-for-mut-t/414/2 "2014-08-20T22:20:45Z")

</div>

I am opposed to this because you can violate soundness with an `&mut int` by introducing data races. The plan is to use `&` and `&mut` for race freedom with a lightweight data parallelism API.

---

<div class="post-metadata">

**Author:** ![glaebhoerl](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/glaebhoerl/32/1978_2.png) [@glaebhoerl](https://internals.rust-lang.org/u/glaebhoerl)\
**Post date:** [August 21, 2014, 11:40pm UTC](https://internals.rust-lang.org/t/impl-t-copy-copy-for-mut-t/414/3 "2014-08-21T23:40:49Z")

</div>

Sure. This was just brainstorming, not a direct proposal. Overall I don’t think I like it that much either - given a reasonable choice between more freedom or stronger guarantees (a.k.a. invariants), I would almost always opt for the guarantees.

But I do think this would be a legitimate option. Obviously it wouldn’t happen in a vacuum, and things which would rely on these guarantees might have to be ruled out (I’m assuming it wouldn’t _currently_ violate soundness, only together with the plans for data parallelism?).

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [March 25, 2019, 8:22am UTC](https://internals.rust-lang.org/t/impl-t-copy-copy-for-mut-t/414/4 "2019-03-25T08:22:48Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.