Allow moves in closures if closure reinitializes moved variables.

[eholk]

Currently, we can't write programs like this:

fn main() {
    let mut x = ~1;

    for int::range(0, 10) {|i|
        let z <- x;
        x = ~(*z * i);
    }
}

At first glance this looks like it should be safe, since any time we move out of x, we also put something back in it. If this really is safe, we should allow it. If this isn't safe, could someone post an example that breaks?

[brson]

I don't think this is safe because the task might fail between the two, leaving the closure in an invalid state.

[eholk]

Presumably moving out of the variable would de-initialize it, so unwinding should do the right thing even in the face of failing tasks.

Perhaps this is a problem if there are destructors...

[brson]

Yes, the problem is that it can still be called.

[eholk]

Here's an example that segfaults. Because the move isn't allowed, I cheated and used unsafe pointers.

fn main() {
    let mut x = ~1;

    class r/& {
        let x: &~int;
        new(x: &~int) {
            self.x = x;
        }
        drop {
            log(error, **self.x);
        }
    }

    let r = r(&x);

    for int::range(0, 10) {|i|
        let z <- unsafe { let x <- *ptr::addr_of(x); x };
        fail;
        //x = ~(*z * i);
    }
}

The last assignment to x has to be commented out because the barrow checker forbids it due to the class instance having an outstanding loan of x. I suspect a similar rule could be used to forbid the move out of x in this case, but make it legal otherwise.

[nikomatsakis]

I've been wanting to extend the liveness check to cover this scenario but I hadn't thought too hard about possible failure cases. Indeed it seems tricky.

[nikomatsakis]

I'm not really sure where the problem is in that example---e.g., it's unclear to me that dtors should be able to access the stack frame and so forth. We have to think about what drop functions can legally do.

[brson]

I hadn't considered the difference here between stack closures and heap closures, and indeed was thinking of the original example as a heap closure. They are both tricky in different ways.

[nikomatsakis]

I think fn@/fn~ should not be permitted to deinitialize upvars. I think fn& should be allowed to do so so long as the variable is reinitialized---this seems no different than any other place where we permit deinitialization in a loop. I think the problem that @eholk highlighted is more general. The same could occur without an fn&, I believe, if you just use a loop.

So in general we need to think harder about what data is accessible from inside a destructor. We also need to think about access to @ boxes, for example, which seems to invite the possibility of resurrection, out-of-order destruction, and other horrible things.

@pcwalton --- interestingly, the need for limits on what a dtor can do would also seem to affect the idea of destructors being "just another interface". Well, it doesn't invalidate the idea, it just means that they are an interface that the compiler will have to treat somewhat specially.

[eholk]

It seems like fn~ could also deinitialize upvars as long as it reinitializes them too, since they have to take ownership of everything in their closure, correct?

[nikomatsakis]

hmm there are two concerns. the first is the possibility of a fail then leading to a dtor. but the other concern would be recursive calls---and those could probably occur with fn& as well.

[eholk]

For the dtor, I thought we zero out data that's been deinitialized, so the dtor would know now to run.

I had forgotten about recursive calls. I was working under the assumption that when a closure is invoked it runs to completion before being invoked again. I guess this isn't actually true.

[nikomatsakis]

@eholk what I meant regarding dtors was rather that they might cause the closure to be invoked even when there is a failure separating the deinit and the reinit

[catamorphism]

Adding RFC label.

[nikomatsakis]

I am going to close this. I have not successfully come up with a simple formulation that ensures there are no recursive calls. For the time being I think we should just write the relevant code with while loops, cells, or unsafety (in decreasing order of desirability).