Pattern-destructing a struct inside a ~-pointer violates linearity

[bblum]

EDIT(bblum): modernized the example

extern mod extra;
use extra::arc;

struct Bar { x: arc::ARC<()> }

impl Drop for Bar {
    fn finalize(&self) {
        error!("%?", self.x.get());
    }   
}

struct Foo { x: Bar }

fn main() {
    let x = ~Foo { x: Bar { x: arc::ARC(()) } };
    let ~Foo { x: _y } = x;
}

This runs the destructor twice and crashes. It does not run the destructor twice if the ~ are removed.

Unlike #3218, this code should compile, because A is the one with the destructor.

[bblum]

More minimal:

struct A { x: (); drop { error!("A"); } } 

fn main() {
    let bp = ~A { x: () };
    let ~_a <- bp; 
}

[bblum]

related is the bicentordinally-older bug, #3024.

[catamorphism]

Never mind my earlier comment; it was so wrong that I deleted it.

[catamorphism]

There are two reasons this is happening:

1. The parser treats patterns on the LHS of a let differently from match patterns. It considers let-LHS patterns irrefutable, and match patterns to be always refutable. The parser makes all bindings by-value if the pattern is refutable. So what this code is doing is copying the contents of the unique box even though the initialization is by-move.
2. The kind checker isn't aware of this, and doesn't check that the RHS is copyable when the statement initializer is <-. That's okay when the pattern is just an ident or _, but not okay if the pattern contains any by-copy bindings.

If I recall correctly, we were going to get rid of <-, so that would be one solution. Another is for the kind checker to be more precise. A third solution is for the parser to treat let patterns the same way as match patterns, but I'm not totally sure what effect that would have. Obviously, pending changes to pattern semantics as described in #3271 affect all of this.

[catamorphism]

Actually, fixing the code to make this work seems like more trouble than it's worth. I'm just going to remove <-, since that was the plan AFAIK.

[bblum]

I kinda feel like it's important to be able to move out of unique boxes when deallocating them. The only alternative is the option dance, which changes your datatypes everywhere else too, uses extra memory, etc. One use case is in arc::unwrap -- internally it uses the option dance at present.

[catamorphism]

...I don't think any of the three possible solutions would prevent moving out of unique boxes when deallocating? Unless I'm missing something. (Getting rid of <-> just means you would write let ~a = move whatever instead of let ~a <- whatever.

[bblum]

Oh okay yeah. I've been thinking of <- foo and = move foo as the same thing. I guess they are not in the compiler. Getting rid of <- seems like the right thing to do no matter what.

[catamorphism]

Heh, re-reading the whole thing, I suspect getting rid of <- doesn't actually solve the problem, and that your original test case will still exhibit the wrong behavior. But I will see.

[catamorphism]

Indeed, the following code still shows the bug:

struct A { x: &mut int, drop { *(self.x) -= 1; error!("A"); } } 
struct B { x: A }

fn main() {
    let mut y = 3;
    let bp = ~B { x: A { x: &mut y } };
    let ~B { x: _a } = move bp;
    assert(y == 2);
}

Fixing this will be part of #3271 -- the problem is right now, the binding of x in the pattern-match is a by-copy binding.

[nikomatsakis]

I thnk this has nothing to do with being a copy binding or not. If a struct has a destructor, you should not be able to move it into a destructuring pattern!