Opt-in copy causes types that shouldn't be Copy to be copy

[Aatch]

Basically, it's now possible to write:

struct Foo { a: int };

impl Drop for Foo { fn drop(&mut self) { } }

impl Copy for Foo { }

and have everything work. This unfortunately means that doing something like let a = b with a Foo will zero b, but not move it.

/cc @nikomatsakis @pcwalton

[nikomatsakis]

I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.

[Aatch]

@nikomatsakis at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.

[ben0x539]

Looks unsafe to me:

struct Foo { a: &'static int }
impl Drop for Foo { fn drop(&mut self) { } }
impl Copy for Foo { }

fn main() {
    static I: int = 42;
    let x = Foo { a: &I };
    let y = x;
    println!("{}\n{}", y.a, x.a);
}

Program received signal SIGSEGV, Segmentation fault.
0x0000555555598e5c in fmt::num::i64.fmt..Show::fmt::he672872527c9858bIvv ()

[nikomatsakis]

I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.

[nikomatsakis]

Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.